Claude constantly looses token for access

[googsvg]

Hi, I'm constantly getting this error message - even though I've allowed access to keychain and I did claude login regularly.
What is wrong with my setup? I guess I'm doing something wrong :)

thanks!

Claude OAuth token expired and delegated Claude CLI refresh failed: Claude keychain did not update after Claude CLI touch.. Run claude login, then retry.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 1, 2026, 1:08 PM ET / 17:08 UTC.

Summary
Keep open: current main can still emit the exact Claude OAuth delegated-refresh failure when expired Claude CLI-owned credentials do not update after a repair attempt, and this fresh report needs maintainer auth/keychain triage rather than cleanup.

Reproducibility: no. high-confidence live reproduction yet; the issue lacks version/setup/log details and live Keychain probing was intentionally not run. Source inspection does show a clear current-main path that emits the exact reported message when expired Claude CLI-owned credentials fail delegated keychain repair.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Manual maintainer review is needed because the user-specific setup is under-specified and the likely fixes touch auth/keychain ownership policy.

Security
Needs attention: This issue is security-sensitive because diagnosis and any repair involve Claude OAuth credentials, Keychain access, and Claude CLI refresh-token ownership.

Review details

Best possible solution:

Collect redacted setup/log details first, then either document the setup-specific remediation or land a narrowly reviewed Claude OAuth/keychain repair that preserves Claude CLI token ownership.

Do we have a high-confidence way to reproduce the issue?

No high-confidence live reproduction yet; the issue lacks version/setup/log details and live Keychain probing was intentionally not run. Source inspection does show a clear current-main path that emits the exact reported message when expired Claude CLI-owned credentials fail delegated keychain repair.

Is this the best way to solve the issue?

Unclear; the safe next step is maintainer auth/keychain triage with redacted diagnostics, not an automated direct-refresh change. Directly refreshing Claude CLI-owned tokens would conflict with the existing token-ownership policy unless maintainers intentionally change that boundary.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The report does not include CodexBar version, macOS version, Claude CLI version, install source, selected Claude provider source, or redacted Console logs, so the user-specific trigger is still unknown.
• I did not run live Claude, OAuth, or Keychain probes because AGENTS.md forbids validation that can display macOS Keychain prompts unless explicitly requested.
• Any code fix in this area must preserve Claude CLI refresh-token ownership and avoid leaking or cross-associating OAuth/keychain data.

Codex review notes: model internal, reasoning high; reviewed against 55a67bbc71c5.

Label changes

Label changes:

• add P2: This is a normal-priority Claude provider auth reliability report with limited blast radius but real user impact.
• add impact:security: Triage and any fix touch OAuth tokens, Keychain access, and sensitive credential ownership boundaries.
• add impact:auth-provider: The issue is directly about Claude OAuth token refresh, Keychain-backed credential routing, and provider login state.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority Claude provider auth reliability report with limited blast radius but real user impact.
• impact:auth-provider: The issue is directly about Claude OAuth token refresh, Keychain-backed credential routing, and provider login state.
• impact:security: Triage and any fix touch OAuth tokens, Keychain access, and sensitive credential ownership boundaries.

Evidence reviewed

Security concerns:

• [medium] Avoid secret disclosure during diagnosis — docs/keychain-prompts.md:15
  Support follow-up should ask for redacted versions, settings, prompt screenshots, and logs, not OAuth tokens, cookie headers, API keys, or Keychain item values.
  Confidence: 0.86
• [medium] Preserve Claude CLI token ownership — Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift:1175
  Changing CLI-owned credentials to refresh directly from CodexBar could desynchronize Claude Code's rotating refresh token and force re-login, so any repair needs maintainer auth review.
  Confidence: 0.82

What I checked:

• Repository policy read: AGENTS.md was read fully; its guidance against live provider/Keychain validation without explicit request and its Claude/keychain notes shaped this source-only review. (AGENTS.md:1, 55a67bbc71c5)
• Vision/auth boundary: VISION.md aligns provider bug fixes with the project but calls provider auth, storage, and privacy-affecting behavior sign-off sensitive. (VISION.md:3, 55a67bbc71c5)
• Exact error path remains: ClaudeUsageFetcher maps a failed delegated refresh attempt into the user-visible Claude OAuth token expired and delegated Claude CLI refresh failed message. (Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift:933, 55a67bbc71c5)
• Keychain-update failure remains: ClaudeOAuthDelegatedRefreshCoordinator returns Claude keychain did not update after Claude CLI touch. when the CLI touch completes without an observed Claude keychain change. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthDelegatedRefreshCoordinator.swift:155, 55a67bbc71c5)
• CLI-owned expired credentials delegate: Expired credentials owned by Claude CLI still throw refreshDelegatedToClaudeCLI instead of using CodexBar's direct refresh path. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift:1175, 55a67bbc71c5)
• Regression coverage locks behavior: Tests expect expired Claude CLI-owned cache credentials to delegate refresh, and usage tests cover delegated retry failure handling. (Tests/CodexBarTests/ClaudeOAuthCredentialsStoreTests.swift:260, 55a67bbc71c5)

Likely related people:

• steipete: Recent current-main commits and the open Claude multi-account decision PR cover Claude OAuth history, CLI isolation review, and auth/product direction adjacent to this report. (role: recent area contributor and product-direction owner; confidence: high; commits: 9a2cc6f50d44, 92bbb7a67073, c57de22c9ffe; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift, docs/claude-multi-account-and-status-items.md)
• RajvardhanPatil07: Merged PR history shows this contributor added the policy that treats detectable Claude CLI storage as Claude CLI-owned and delegates refresh instead of spending the rotating token from CodexBar. (role: introduced token-ownership policy; confidence: high; commits: 3488587856c7; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, Tests/CodexBarTests/ClaudeOAuthCredentialsStoreCLIStorageOwnershipTests.swift)
• ratulsarna: History search ties the original Claude OAuth refresh handling and delegated refresh coordinator work to this contributor, which is the feature path surfacing the current error. (role: feature-history contributor; confidence: medium; commits: fa7256fda7ba; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthDelegatedRefreshCoordinator.swift, Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift)
• derekszen: The merged CLI OAuth isolation PR changed runtime gating around delegated refresh while explicitly preserving app/user-initiated repair, making it relevant context for this app-side report. (role: adjacent runtime-boundary contributor; confidence: medium; commits: 3bc978114747, 24490b6434d4; files: Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift, Sources/CodexBarCLI/CLIUsageCommand.swift, TestsLinux/ClaudeOAuthDelegatedRefreshLinuxTests.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

Thanks for the report. I audited the current main auth path at c3d33308a without reading any real credentials or invoking Keychain/browser prompts.

This is not fixed by #1813: that PR clears stale Claude quota/token-history UI state when a credential change is detected, including a cancelled/superseded refresh. It does not change Claude token refresh. Current main can still produce this exact error when all of these happen:

1. the cached Claude CLI-owned OAuth credential is expired;
2. the delegated Claude /status touch completes without an observable Keychain change; and
3. the post-touch credential reload still cannot obtain a valid credential.

There are already bounded recovery paths: a fresh credential that is silently readable is accepted before delegation, an observed Keychain update is synced after delegation, and the post-touch reload is attempted even when the coordinator reports no observed change. Stubbed/no-UI regression suites for those paths are green (10 coordinator tests, 3 recovery tests, and 15 credential-swap cleanup tests). That leaves the reporter-specific trigger unresolved; changing refresh ownership speculatively would be unsafe.

Could you add these redacted details?

• CodexBar version and install source (GitHub release, Homebrew, or Sparkle), macOS version, and claude --version output.
• Claude source selected in CodexBar (Auto, OAuth, CLI, or Web) and the Keychain access mode shown in Settings.
• Whether you use CLAUDE_CONFIG_DIR, claude-swap/cswap, or another account switcher. A yes/no answer is enough; do not post the directory path or account identifiers.
• Immediately after claude login, does a normal Claude request succeed? Then does one user-initiated CodexBar refresh fail immediately? Does quitting and reopening CodexBar change the result?
• One redacted log slice from that single failed manual refresh: Settings -> Debug -> enable file logging, set Verbosity to Verbose, reproduce once, then Open Log File. Please include only lines around Claude OAuth credentials considered expired, Claude OAuth delegated refresh, Claude keychain, and post-delegation retry failed. Remove usernames, emails, and local paths. Do not post tokens, cookie headers, Authorization values, or Keychain item values.

#1812/#1756 remain the separate multi-account/product decision path. If this only occurs with a custom Claude config/account switcher, we should route it there rather than silently broadening native credential discovery. If it occurs on the default single-account setup, the redacted trace should distinguish a CLI-touch failure from a Keychain observation/reload defect and give us a narrow regression target.

Source evidence: delegated change observation, post-delegation reload and error mapping, and #1813 credential-change UI cleanup.