Claude Authorize Issue

[phuchong89]

Claude OAuth credentials repeatedly disappear after successful authentication

Environment

• CodexBar: 0.50.0 (121)
• macOS: 27 Public Beta
• Claude Code: Latest
• Apple Silicon Mac

Summary

Claude authentication succeeds and usage appears correctly.

After several minutes, CodexBar loses the OAuth credentials and displays:

Claude OAuth credentials not found. Run claude to authenticate.

Running the authentication flow again fixes it temporarily, but the problem always returns.

Steps to reproduce

1. Open CodexBar.
2. Authenticate Claude when prompted.
3. Confirm Claude usage is displayed correctly.
4. Wait several minutes.
5. Claude usage disappears.
6. The message "Claude OAuth credentials not found. Run claude to authenticate." appears again.

Expected

Claude should remain authenticated until the OAuth token actually expires.

Actual

CodexBar repeatedly loses the Claude OAuth credentials and requires re-authentication even though Claude Code itself is still logged in.

Additional notes

• Claude Code continues to function normally.
• Re-authentication only fixes the issue temporarily.
• This appears similar to issues Claude login pins usage source to OAuth and disables Auto fallback #1970 and Claude provider: Claude Code-credentials keychain item holds only mcpOAuth entries on Claude Code 2.1.x → ClaudeOAuthCredentialsError + hourly "delegated CLI refresh" opens the default browser #1844, but authentication initially succeeds before failing again.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 15, 2026, 8:34 AM ET / 12:34 UTC.

Summary
Keep open for maintainer-guided diagnosis: this is a current v0.50.0 provider-authentication report, but the exact credential route that becomes unavailable is not established. Likely related people: Peter Steinberger — recent Claude auth/release-boundary contributor (medium confidence).

Reproducibility: no. the report supplies a plausible v0.50.0 path, but no redacted after-failure source-selection or credential-read evidence identifies which current route fails, and live Keychain probing was not authorized.

Ways to help us reproduce this

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

Maintainer decision needed

Question	Recommendation
Should maintainers require a redacted after-failure credential-routing diagnostic before changing Claude OAuth storage or fallback behavior for this current-release report?	Request route-level diagnostics: Ask for redacted selected-source and credential-read diagnostics captured immediately after the failure, then route a confirmed owned path to a focused fix.

Why: The same visible not-found message can result from multiple credential sources and source selections, while provider-auth changes require deliberate handling under the repository vision.

Next step
A redacted after-failure diagnostic is needed to identify the failing credential route before a safe provider-auth repair can be scoped.

Review details

Best possible solution:

Obtain a redacted diagnostic immediately after failure that records the selected source and credential-read outcome, then add a focused regression only for the confirmed owned failure path while preserving Auto fallback.

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

No: the report supplies a plausible v0.50.0 path, but no redacted after-failure source-selection or credential-read evidence identifies which current route fails, and live Keychain probing was not authorized.

Is this the best way to solve the issue?

Unclear: current Auto fallback and source-preservation behavior are the intended narrow path, but the report needs route-level evidence before changing credential storage or fallback policy.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Changing credential routing without identifying whether the failure is CodexBar cache, credentials-file, Keychain access, or an unavailable fallback could weaken the intended provider-auth boundary or break working setups.

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

Label changes

Label justifications:

• P2: The report describes a repeatable current-release Claude authentication disruption with limited provider-specific blast radius.
• impact:auth-provider: The reported failure is loss of the Claude OAuth credential route used to retrieve provider usage.

Evidence reviewed

What I checked:

• Current source-selection contract: Current documentation defines the app Auto order as OAuth API → CLI PTY → Web API, and says successful login preserves the selected source; Auto keeps CLI/Web fallback when OAuth is unusable. (docs/claude.md:24, f15f142a7787)
• Current fallback implementation: The source planner emits OAuth, CLI, and Web steps for app Auto, while explicit OAuth retains a CLI fallback only; the report does not identify which selected source or step failed. (Sources/CodexBarCore/Providers/Claude/ClaudeSourcePlanner.swift:176, f15f142a7787)
• Error is not a token-expiry diagnosis: The displayed text maps specifically to the credential store’s notFound state, distinct from its denied-Keychain, missing-token, and refresh-failed states. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentialModels.swift:251, f15f142a7787)
• Existing regression coverage: Current tests cover preserving every selected usage source after successful Claude login and intentionally retaining a failed CodexBar-owned OAuth cache across refreshes, but do not establish this reporter’s post-login disappearance path. (Tests/CodexBarTests/ClaudeOAuthUpgradeCompatibilityTests.swift:756, f15f142a7787)
• History and release provenance: The available shallow-history blame attributes the current Claude docs and routing surface to the v0.50.0 release boundary; v0.50.0 contains commit 0e453c4, the version named by the report. (docs/claude.md:63, 0e453c4a5b2a)
• Prior discussion: The prior ClawSweeper review kept this current-release report open because a redacted after-failure diagnostic is needed to distinguish a credential-cache/read failure from an unavailable fallback.

Likely related people:

• Peter Steinberger: Available blame on the current Claude routing documentation and current-main release history points to Peter; the shallow checkout does not establish earlier feature authorship. (role: recent Claude auth and release-boundary contributor; confidence: medium; commits: f15f142a7787, 0e453c4a5b2a; files: docs/claude.md, Sources/CodexBarCore/Providers/Claude/ClaudeSourcePlanner.swift, Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentialModels.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 — the "works, then disappears after several minutes, Claude Code still logged in" shape on 0.50.0 is being tracked in the canonical investigation at #2516, and macOS 27 beta adds a known wrinkle: the beta's Keychain/TCC behavior can make a previously granted "Always Allow" read start failing silently on later background refreshes (each new process PID may re-require consent), which presents exactly as credentials "disappearing" between refreshes while claude itself keeps working.

To pin your instance down, please add to #2516:

1. Settings → Providers → Claude → Usage source (Auto/OAuth/CLI), and the Keychain prompt policy if you changed it.
2. Whether a manual refresh (⌘R on the Claude card) restores usage without re-running authentication.
3. One log capture across a failure:

pkill -x CodexBar || true
defaults write com.steipete.codexbar debugFileLoggingEnabled -bool true
defaults write com.steipete.codexbar debugLogLevel -string verbose
open -a CodexBar

wait until the error reappears, then attach the sanitized tail of ~/Library/Logs/CodexBar/CodexBar.log (the lines around the OAuth read failure are the decisive part).

Consolidating there so the evidence stays in one place — closing this as a duplicate of #2516.