Omnara + Claude Code Auth Failure On M3

Date: 2026-06-30

Context

M5 Omnara UI was used to create and inspect sessions running on M3-Laptop-Server.local.
Claude Code appeared signed in, but Omnara-created Claude Code sessions were failing with:

Claude Code: Failed to authenticate. API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"Invalid authentication credentials"}}

Example request IDs from failing UI sessions:

• req_011CcaFXFZuKjoZ5Pf7KeDWT
• req_011CcaFva6GMhQ5xgNyWT2ey

What Worked

• Direct Claude Code on M3 worked: /opt/homebrew/bin/claude, version 2.1.172.
• Direct ~/.omnara/bin/omnara-claude, version 2.1.118, worked.
• Direct stream-json style runs with Omnara-like environment worked.
• Manual Omnara daemon started over SSH worked through the M5 Omnara UI:

env CLAUDE_CODE_SAFE_MODE=1 ~/.omnara/Omnara.app/Contents/MacOS/omnara daemon run-service

Verified successful UI sessions:

• d927e245-a07a-4a3a-ba2e-4f642d6abf25 returned manual daemon ui ok.
• 243eee21-f068-413b-aa9d-576a16c779b4 returned no shim manual ok.

What Did Not Fix It

• Adding CLAUDE_CODE_SAFE_MODE=1 to the persistent LaunchAgent.
• Wrapping the LaunchAgent in /usr/bin/env while stripping XPC_SERVICE_NAME, XPC_FLAGS, and SSH_AUTH_SOCK.
• Temporarily adding ~/.omnara/bin/claude -> ~/.omnara/bin/omnara-claude.

Current State

• Manual Omnara run-service PID on M3: 78942.
• com.omnara.daemon LaunchAgent is unloaded.
• LaunchAgent plist was restored to its original file but not loaded.
• claude resolves to /opt/homebrew/bin/claude.
• claude --version reports 2.1.172 (Claude Code).
• ~/.omnara/bin/claude shim is absent.

This is a working workaround, not a durable fix. It likely will not survive logout or reboot.

Best Diagnosis

The failure appears specific to the Omnara daemon/session context when started by launchd. It does not look like a basic Claude login problem, wrong Claude binary, bad visible env var, or M5 UI problem.

Some hidden launchd/process/session context may be causing Claude Code to select or send invalid credentials even though the visible child environment did not show ANTHROPIC_API_KEY, Bedrock, Vertex, or related provider settings.

Questions For Omnara / Claude Code Team

1. Does Claude Code have known differences when launched under macOS launchd versus a login shell or PTY?
2. Which files or keychain entries does Claude Code read for subscription/OAuth auth, and can launchd context change which token store is selected?
3. Does Omnara's daemon or Claude wrapper ever inject, cache, or translate Anthropic credentials separately from the user's Claude Code login?
4. Can Omnara expose the exact Claude child process argv, environment, parent PID chain, stdio type, and resolved auth source for failed runs?
5. Are 401 request IDs enough for Anthropic/Claude Code support to identify whether the request used OAuth, an API key, or some invalid cached credential?
6. Is CLAUDE_CODE_SAFE_MODE=1 expected to affect auth behavior, or only shell/tool initialization?
7. Is there a supported way for Omnara to start its daemon from a login-shell/PTY-equivalent context on macOS?

Suggested Next Tests

1. Compare full process ancestry, session, TTY, and security context for a working manual daemon versus failing LaunchAgent daemon.
2. Test a persistent wrapper that starts Omnara run-service from a login shell or tmux/PTY context rather than directly from launchd.
3. Instrument the Claude child process under both daemon modes: argv, cwd, env, stdio, parent PID chain, and config/cache paths.
4. Re-test after a full M3 logout/reboot to confirm the workaround is not persistent and the LaunchAgent path still fails.
5. Try a second authenticated macOS user or clean Claude Code config only if the team thinks token-store selection is the likely cause.