Claude auth breaks every ~8h: OAuth token never reaches chat sessions (SDK `env` replaces process.env)

[wisamamid]

Version: v0.2.94 (also present on main @ 6ce6383)
Platform: macOS (packaged app)
Auth: Claude subscription (OAuth) — CLI also logged in, so provider resolves to cli_keychain

Symptoms

• Dorabot works right after signing in with a Claude account, then starts failing with Failed to authenticate. API Error: 401 Invalid authentication credentials after ~8 hours (access-token lifetime).
• Every new context window is blocked once this happens; re-authenticating fixes it temporarily, then the cycle repeats.
• The UI keeps reporting the provider as connected while every run 401s.

Root cause

Chat sessions never receive the OAuth token that dorabot manages. Three things combine:

1. agent.ts passes an explicit env to the SDK, built from a login-shell snapshot cached once at startup.
   cleanEnvForSdk() → getShellEnv() (src/agent.ts:75-131) resolves the user's login-shell environment a single time and caches it in _resolvedShellEnv. This snapshot obviously does not contain CLAUDE_CODE_OAUTH_TOKEN (dorabot only sets that on process.env after login/refresh).

2. The Claude Agent SDK does NOT merge options.env with process.env — it replaces it.
   In @anthropic-ai/claude-agent-sdk (checked 0.3.211), the subprocess env is options.env ? {...options.env} : {...process.env}. So everything ClaudeProvider does with process.env.CLAUDE_CODE_OAUTH_TOKEN (constructor, ensureOAuthToken(), completeOAuthLogin() — src/providers/claude.ts) is invisible to actual chat subprocesses spawned via agent.ts (env: cleanEnvForSdk() at src/agent.ts:258 and :438).

3. Result: chats silently depend on the Claude Code CLI's own keychain credentials.
   With no auth env var, the spawned CLI falls back to its own stored login. When that access token expires (~8h) and the headless child can't refresh it cleanly (refresh-token rotation races between dorabot-spawned children and the user's own terminal sessions), every session 401s. Re-authenticating in dorabot stores fresh tokens in dorabot's keychain entry, which chat sessions never read, so nothing is actually fixed — the loop repeats.

Two aggravating factors that mask the bug:

• verifyAuth() (src/providers/claude.ts) calls query() without an env option, so its subprocess inherits process.env including the fresh token → the post-login verification passes even though real sessions are spawned with a different (token-less) environment.
• _cliHasAuth is cached once per process and the cli_keychain branch of getAuthStatus() unconditionally returns authenticated: true, tokenHealth: 'valid' without ever validating, so the UI reports connected while runs 401.

Fix

Inject the freshly-ensured credentials into the per-run env in ClaudeProvider.query() (src/providers/claude.ts). This makes sessions independent of the CLI keychain state and lets dorabot's own refresh machinery (ensureOAuthToken + scheduleTokenRefresh) do its job:

async *query(opts: ProviderRunOptions): AsyncGenerator<ProviderMessage, ProviderQueryResult, unknown> {
    const method = getActiveAuthMethod();
    if (method === 'dorabot_oauth') {
      await ensureOAuthToken();
    }

    // The SDK REPLACES the subprocess env with opts.env (no merge with
    // process.env), and opts.env is a login-shell snapshot cached at startup.
    // Inject fresh credentials so every new session authenticates reliably.
    if (opts.env) {
      if (method === 'api_key') {
        const key = getApiKey();
        if (key) opts.env.ANTHROPIC_API_KEY = key;
      } else if (hasOAuthTokens()) {
        // Covers dorabot_oauth AND cli_keychain-with-dorabot-tokens: the env
        // var takes precedence over the CLI keychain in the child process.
        const token = await ensureOAuthToken();
        if (token) opts.env.CLAUDE_CODE_OAUTH_TOKEN = token;
        else delete opts.env.CLAUDE_CODE_OAUTH_TOKEN; // never pass a stale token
      }
    }
    // ... rest unchanged

I've been running this patch against the compiled gateway/dist/providers/claude.js of the packaged v0.2.94 app and the 8-hour auth loop is gone.

Suggested follow-ups (separate, smaller)

• Re-check _cliHasAuth periodically (or on auth errors) instead of caching once per process.
• Make verifyAuth() use the same env-construction path as real runs so verification can't pass while sessions fail.
• Consider preferring dorabot_oauth over cli_keychain in getActiveAuthMethod() when dorabot has its own tokens — dorabot can refresh those itself, whereas it has no control over the CLI keychain entry.

Repro

1. Log in to Claude Code CLI in a terminal and sign in to dorabot with a Claude account (so the provider resolves to cli_keychain).
2. Use dorabot normally; wait for the CLI access token to expire (~8h, or force it by revoking/clearing the CLI's keychain entry Claude Code-credentials).
3. Open a new context window → 401 Invalid authentication credentials.
4. Re-authenticate in dorabot → verification passes, sessions still (or soon again) 401.

[ankit-thebigred]

Confirming this still reproduces on 0.2.97 (macOS arm64, packaged app), and the code paths you identified are unchanged on main today:

• src/agent.ts:74-83 — getShellEnv() caches a login shell env snapshot once in the module level _resolvedShellEnv, captured before dorabot has ever set CLAUDE_CODE_OAUTH_TOKEN.
• src/agent.ts:115-131 — cleanEnvForSdk() wraps that stale snapshot and it is passed as env: on every run.
• src/providers/claude.ts:743-746 — query() calls ensureOAuthToken(), which sets process.env.CLAUDE_CODE_OAUTH_TOKEN.
• src/providers/claude.ts:910 — but env: opts.env is what actually reaches the SDK, and that object never receives the refreshed token.

Your diagnosis looks right to me. I have not sent a patch because you already have a validated one and it is your find. Two additional things I ran into while confirming it, in case they are useful.

1. getActiveAuthMethod() can report none on a working install.

cliHasOwnAuth() (src/providers/claude.ts:346) shells out to a globally installed claude binary. On a packaged install where the standalone CLI was never separately installed, that execSync throws and _cliHasAuth is cached as false. On this machine:

• no claude binary on PATH or in the usual install locations
• no ~/.dorabot/.claude-oauth.json
• no ~/.dorabot/.anthropic-key
• no ANTHROPIC_API_KEY

so getActiveAuthMethod() returns none, while chats work perfectly because the SDK's own bundled CLI authenticates against the macOS keychain entry Claude Code-credentials directly.

The practical consequence is bigger than a wrong label: because the method is not dorabot_oauth, ensureOAuthToken() is never called, so the refresh machinery in this file never runs at all. Auth ends up depending entirely on a keychain credential that dorabot neither owns nor refreshes. That may explain why the failure is unrecoverable in-app for some of us rather than just needing a new session.

2. verifyAuth() is a false-positive health check.

It calls the SDK's query() without an explicit env, so it inherits process.env and sees the refreshed token that real runs never get. It can therefore report healthy while every actual chat 401s, which matches the "UI keeps reporting the provider as connected" symptom in your report. Whatever the fix here, that check probably needs to build its env the same way real runs do, or it will keep masking this class of bug.

Related: _cliHasAuth (:343) is detected once and cached for the lifetime of the gateway process, so installing or logging into the CLI while dorabot is running is never noticed either.

Happy to send a PR for any of this if it is useful, but did not want to step on yours.

[ankit-thebigred]

Following up on my earlier comment, and I need to correct part of it.

What I got wrong. I said getActiveAuthMethod() returns 'none' on this install and that auth was really riding the SDK's bundled CLI reading the macOS keychain entry Claude Code-credentials. That is wrong. I had only looked for a credentials file, did not find one, and concluded from its absence. Auth resolves to dorabot_oauth, and the tokens live in the keychain under service dorabot, account anthropic-oauth. The Claude Code-credentials entry I pointed at had in fact expired seven weeks earlier, so it could not have been what was working. Sorry for the noise.

On the env-propagation theory. I checked it directly this time rather than reasoning from the code. Reading /proc-equivalent state for the live SDK child (ps eww) shows CLAUDE_CODE_OAUTH_TOKEN present in its environment with a value matching the current keychain token exactly. So on this install class spawn-time injection is already working, which means merging fresh creds into opts.env would be a no-op here. That does not invalidate @wisamamid's patch, which may well be right for the cli_keychain path, and he actually reproduced his case where I did not. I am deliberately not opening a competing PR against it.

What is actually breaking this install. The gateway log has 49 refresh attempts and 48 failures:

[claude] access token expired or expiring, refreshing...   49x
[claude] token refresh failed                              48x

Two causes. getaddrinfo ENOTFOUND console.anthropic.com, which is the machine waking from sleep with the refresh timer already due and the network not yet up. And token refresh failed: 400, which looks like the rotating refresh_token being spent twice by concurrent ensureOAuthToken() calls, since it runs at the top of every turn with no single-flight guard.

Either way the outcome is the same, because scheduleTokenRefresh() treats three failures inside a ~15 second window as terminal:

if (!refreshed) {
  emitAuthRequired('OAuth refresh failed after retries');
  nextRefreshAt = null;
  return;              // nothing ever re-arms it
}

After that the process has no scheduled refresh. The access token runs out its remaining life and everything 401s until relaunch. That matches the reported symptom precisely, including why only a restart helps and why it recurs at irregular intervals.

I have put a fix in #42: re-arm with a capped backoff instead of clearing the timer, single-flight the refresh, and re-check token health when the timer fires. It is orthogonal to the env question, so both changes can land independently.