Suggest edit — omnara-claude-code-auth-2026-06-30

Title

Name

Note

---
visibility: unlisted
---

# 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:

```text
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:

```bash
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.