Claude login pins usage source to OAuth and disables Auto fallback

[Chipagosfinest]

Summary

Successful Claude login can persist the Claude usage source as oauth, which disables the auto fallback path. If the current Claude CLI login reports success but CodexBar cannot read OAuth credentials afterward, the app can get stuck repeatedly asking for Claude credentials.

Local repro / observed behavior

Environment:

• CodexBar app: 0.41.0 (/Applications/CodexBar.app, build commit 27cff88a1)
• Claude Code: 2.1.201
• macOS app install, default menu-bar flow

What I saw locally:

1. CodexBar had Claude enabled with source: "oauth" in ~/.config/codexbar/config.json.
2. Running codexbar --provider claude --format json --pretty returned:
   Claude OAuth credentials not found. Run claude to authenticate.
3. App logs included a keychain cache read failure for oauth.claude.
4. The menu-bar app kept asking for Claude credentials, even though Claude Code itself was installed and authenticated enough for CLI usage.

Workaround:

• Changing the Claude source in ~/.config/codexbar/config.json from oauth to auto, validating config, and restarting CodexBar stopped the credential prompt loop locally.

Suspected root cause

runClaudeLoginFlow() currently forces:

self.settings.claudeUsageDataSource = .oauth

after the login runner reports success.

That makes the app persist an OAuth-only state immediately after the setup flow. If CodexBar cannot read the OAuth credentials, it never gets to use the app's fallback behavior. Keeping the source on auto is less brittle: OAuth can still be preferred when readable, but CLI/Web fallback remains available when OAuth is not usable.

Related issues

• Claude constantly looses token for access #1823 tracks broader Claude token/access loss.
• 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 fixed a related mcpOAuth/browser-launch path, but this looks narrower: the login flow itself persists the fallback-hostile source after success.

Expected behavior

A successful Claude setup flow should leave CodexBar in a resilient source mode. Out of the box, login should not pin users to OAuth-only if Auto fallback is available and intended as the safer default.

[clawsweeper]

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

Summary
Keep open: current main still forces Claude's usage source to OAuth after a successful login, which bypasses Auto's OAuth-to-CLI-to-Web fallback. The fix is narrow, but current docs also describe the OAuth pin and VISION.md marks provider-auth behavior changes as sign-off-sensitive, so this needs maintainer direction rather than cleanup.

Reproducibility: Source-level yes for the central issue: current main still writes .oauth after successful login and explicit OAuth has no fallback. The full prompt loop was not live-reproduced because it depends on local Claude/Keychain state and AGENTS.md forbids prompt-triggering probes without explicit request.

Ways to help us reproduce this

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

Next step
Manual review is needed because changing post-login source persistence conflicts with current docs and affects provider-auth behavior that VISION.md marks sign-off-sensitive.

Maintainer decision needed

• Question: Should a successful Claude login continue to persist OAuth-only mode, or should the default login flow preserve Auto fallback unless the user explicitly chose OAuth?
• Rationale: Current code and docs intentionally select OAuth after login, but the issue shows that choice can block provider setup when OAuth credentials are not readable; VISION.md says provider-auth behavior changes need maintainer sign-off.
• Likely owner: steipete — steipete is tied to the current login/source behavior and is the clearest owner for provider-auth product direction in this area.
• Options:
  • Preserve Auto by default (recommended): Do not override Auto to OAuth after login; keep OAuth preferred inside Auto when readable, and update docs/tests for the resilient setup behavior.
  • Keep OAuth pinning: Leave successful login as OAuth-only and improve the error/recovery copy so users can switch to Auto, CLI, or Web manually.
  • Conditional pin after verification: Set OAuth only when a post-login no-prompt credential read succeeds, otherwise keep or restore Auto fallback.

Security
Needs attention: Security-sensitive auth review is needed because the issue and any fix touch Claude OAuth source routing, Keychain reads, and credential-recovery behavior.

Review details

Best possible solution:

Make Claude login preserve Auto/default source and offer an in-product Switch to Auto or retry path when OAuth cannot be read, while keeping explicit OAuth strict only when the user intentionally chose it.

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

Source-level yes for the central issue: current main still writes .oauth after successful login and explicit OAuth has no fallback. The full prompt loop was not live-reproduced because it depends on local Claude/Keychain state and AGENTS.md forbids prompt-triggering probes without explicit request.

Is this the best way to solve the issue?

Unclear until maintainer direction is set. If accepted, the narrowest maintainable fix is to stop overriding Auto/default source during Claude login, preserve explicit user-selected OAuth, and cover the behavior with focused settings/login-source tests plus docs.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The full prompt loop depends on local Claude CLI and Keychain state that was not live-probed because repository policy forbids prompt-triggering validation without an explicit request.
• Changing post-login source persistence affects provider auth routing and must preserve explicit user choices, OAuth strict mode, Keychain prompt policy, and documented recovery behavior.

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

Label changes

Label changes:

• add P0: The report describes default Claude provider setup entering a credential prompt loop after successful login, with recovery requiring config edits and restart rather than guided in-product recovery.
• add impact:security: The failing path and any fix touch OAuth credentials, Keychain reads, and provider-auth boundaries.
• add impact:auth-provider: The issue is directly about Claude OAuth, Auto fallback, and provider source routing.
• add impact:ux-release-blocker: A community user can be blocked in Claude auth/provider setup and the demonstrated workaround is a technical config-file recovery path.
• 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:fix-shape-clear: 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:

• P0: The report describes default Claude provider setup entering a credential prompt loop after successful login, with recovery requiring config edits and restart rather than guided in-product recovery.
• impact:ux-release-blocker: A community user can be blocked in Claude auth/provider setup and the demonstrated workaround is a technical config-file recovery path.
• impact:auth-provider: The issue is directly about Claude OAuth, Auto fallback, and provider source routing.
• impact:security: The failing path and any fix touch OAuth credentials, Keychain reads, and provider-auth boundaries.

Evidence reviewed

Security concerns:

• [medium] Preserve explicit OAuth and Keychain boundaries — Sources/CodexBar/Providers/Claude/ClaudeLoginFlow.swift:24
  A fix should not silently broaden credential reads or weaken explicit OAuth strictness while changing the default login source behavior.
  Confidence: 0.82
• [medium] Keep diagnostics redacted
  Follow-up should use redacted source-selection, version, and log details only, not OAuth tokens, cookie headers, Authorization values, or raw Keychain payloads.
  Confidence: 0.78

Acceptance criteria:

• swift test --filter ClaudeSourcePlannerTests
• swift test --filter SettingsStoreTests
• swift test --filter ClaudeOAuthTests
• make check

What I checked:

• Repository policy read: AGENTS.md was read fully; its guidance against live Claude, OAuth, and Keychain probes without an explicit request constrained this review to source, docs, history, and GitHub discussion. (AGENTS.md:1, aa401f1d8b74)
• Current source still pins OAuth: After a successful Claude login, runClaudeLoginFlow enables Claude and assigns claudeUsageDataSource to .oauth. (Sources/CodexBar/Providers/Claude/ClaudeLoginFlow.swift:24, aa401f1d8b74)
• Auto fallback exists only in Auto mode: The Claude source planner orders app Auto as OAuth, CLI, then Web, while explicit OAuth is a single OAuth step with no fallback. (Sources/CodexBarCore/Providers/Claude/ClaudeSourcePlanner.swift:171, aa401f1d8b74)
• Settings UI describes Auto fallback: The Providers settings picker tells users that Auto falls back to the next source if the preferred one fails. (Sources/CodexBar/Providers/Claude/ClaudeProviderImplementation.swift:193, aa401f1d8b74)
• Docs currently document the conflicting login behavior: The Claude docs say successful OAuth login enables Claude and selects OAuth as the usage source, so changing this behavior needs a maintainer decision and doc/test updates. (docs/claude.md:82, aa401f1d8b74)
• Related issue context checked: The linked browser-launch issue was fixed by merged pull request Fix #1844: block background Claude delegated refresh and mcpOAuth-only keychain touch #1848, while its maintainer comment leaves broader Claude Code OAuth storage discovery tracked in Claude constantly looses token for access #1823; neither changes this login-source pin. (a27c9b094e61)

Likely related people:

• steipete: Current blame for the login-source assignment points to the v0.41.0 release commit, and history shows steipete authored the Claude Code sign-in flow and earlier OAuth-primary source behavior. (role: recent area contributor and likely decision owner; confidence: high; commits: a83a83fa4131, 30b476237588, 7d0812540dd2; files: Sources/CodexBar/Providers/Claude/ClaudeLoginFlow.swift, Sources/CodexBar/Providers/Claude/ClaudeProviderImplementation.swift, Sources/CodexBarCore/Providers/Claude/ClaudeSourcePlanner.swift)
• Yuxin-Qiao: Merged pull request Fix #1844: block background Claude delegated refresh and mcpOAuth-only keychain touch #1848 fixed the related MCP-only keychain/background delegated-refresh problem cited by this issue. (role: adjacent auth/keychain fix contributor; confidence: medium; commits: a27c9b094e61; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthDelegatedRefreshCoordinator.swift, Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift)
• ratulsarna: Git history ties earlier Claude OAuth diagnostics, refresh, and source-selection behavior to this contributor's work in the same provider area. (role: feature-history contributor; confidence: medium; commits: 8fa2d257211e, 85090e870b75; files: Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift, Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, Tests/CodexBarTests/ClaudeOAuthTests.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.

[Chipagosfinest]

Verified against current upstream/main before opening a PR:

• Refreshed steipete/CodexBar main locally on 2026-07-07.
• Sources/CodexBar/Providers/Claude/ClaudeLoginFlow.swift still sets self.settings.claudeUsageDataSource = .oauth after a successful Claude login.
• The settings UI still documents Auto as the fallback-capable mode: Auto falls back to the next source if the preferred one fails.
• SettingsStoreTests still expects the default Claude usage source to be .auto.
• A dry merge of the proposed one-commit fix into refreshed upstream/main has no conflict.

This still looks live and narrow: the default source is Auto, but the login flow can persist OAuth-only immediately after successful setup, removing the fallback path that fixed the local prompt loop.

[LeoLin990405]

Confirmed live on current main (CodexBar 0.41.0), reproduced non-destructively via the CLI --source flag (account email redacted):

$ codexbar usage --provider claude --source oauth
Error: Claude OAuth credentials not found. Run `claude` to authenticate.

$ codexbar usage --provider claude --source auto
== Claude 2.1.205 (web) ==
Session: 82% left  |  Weekly: 93% left  |  Plan: Claude Max 20x
Account: <redacted>

With the source pinned to oauth, the app hard-fails when the OAuth credentials aren't readable (here the oauth.claude keychain read), with no fallback — which is exactly the credential-prompt loop this issue describes. Forcing auto recovers immediately via the Web fallback on the same machine, same login state.

This lines up with the root cause in #1971: runClaudeLoginFlow() persisting .oauth after a successful login removes Auto's OAuth → CLI → Web fallback. Leaving the source on .auto (the documented, fallback-capable default, per SettingsStoreTests) keeps the recovery path intact. +1 to that direction.