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

[mira-semera]

TL;DR: On Claude Code 2.1.196 the keychain item Claude Code-credentials no longer contains the Claude OAuth credentials CodexBar expects — it holds only mcpOAuth state for MCP servers. CodexBar therefore fails to parse credentials (ClaudeOAuthCredentialsError), treats the token as expired, and every ~64 minutes runs a "delegated Claude CLI refresh" whose recovery path calls /usr/bin/open — launching the user's default browser (Firefox), even right after the user quit it. Before I switched Usage source to OAuth API and Claude cookies to Manual, the same failure also drove a much faster retry loop (opens every 20 s–3 min).

Environment

• CodexBar 0.37.2 (build 92) — latest per appcast as of 2026-07-02
• macOS 26.3 (25D125)
• Claude Code CLI 2.1.196, Enterprise plan, logged in and working (sessions run fine)
• Default browser: Firefox 152.0.3
• Settings already tried: Usage source = OAuth API, Claude cookies = Manual, provider toggled off

Smoking gun — keychain payload

security find-generic-password -s "Claude Code-credentials" -w returns a 1562-byte JSON whose only top-level key is mcpOAuth (entries for MCP servers: craft, plugin:slack:slack, kosik, plugin:figma:figma; their accessToken fields are even empty strings). There is no Claude OAuth key (no accessToken/refreshToken/expiresAt for claude.ai). Claude Code evidently stores its main OAuth token elsewhere now.

This matches CodexBar's log exactly:

[com.steipete.codexbar:claude-usage] Claude keychain security CLI output invalid; falling back
  (callerInteraction=background parse_error_type=ClaudeOAuthCredentialsError payload_bytes=1561 reader=securityCLI status=0)
[com.steipete.codexbar:claude-usage] Claude OAuth delegated refresh touch did not update Claude keychain
[com.steipete.codexbar:claude-usage] Claude OAuth delegated refresh attempted (outcome=attemptedFailed)

The dropdown shows: "Claude OAuth token expired and delegated Claude CLI refresh failed: Claude keychain did not update after Claude CLI touch. Run claude login, then retry." Re-login does not help — the CLI writes the token to the new location, not into Claude Code-credentials.

Browser-opening evidence

Every delegated refresh ends in an open call that launches the default browser. macOS tccd attribution:

responsible={TCCDProcess: identifier=com.steipete.codexbar, .../CodexBar.app/Contents/MacOS/CodexBar}
accessing={TCCDProcess: identifier=com.apple.open, binary_path=/usr/bin/open}

LaunchServices: _LSLaunchRB(org.mozilla.firefox, event=GURL/GURL, ...).

Cadence over one night (exact ~64 min 12 s period): 23:12:55, 00:17:07, 01:21:19, 02:25:31, 03:29:43, 04:34:01, 05:38:13, 06:42:13, 07:46:13, 08:50:25.

Before switching Usage source to OAuth API + cookies to Manual, the same parse failure drove opens every 20 s–3 min (cooldown default claudeOAuthDelegatedRefreshCooldownIntervalSecondsV1 = 20).

Quitting CodexBar stops the launches immediately (verified against the predicted next tick).

Expected

1. Support the current Claude Code credential storage (2.1.x) — read the token from its new location instead of expecting it inside Claude Code-credentials.
2. Never call open/launch a browser from a background refresh path. Surface a menu badge / "Re-authenticate" action gated behind an explicit user click, with backoff and a hard cap.

Why this matters

A background menu-bar app repeatedly launching the user's browser (even seconds after they quit it) reads as malware-like behavior (see also #1681) and is disruptive. The failure is silent-but-visible: users see their browser "haunted" with no clue CodexBar is the cause; it took unified-log attribution-chain forensics to find it.

Related

#1823 (Claude constantly loses token), #1161 (CodexBar can desync Claude Code's OAuth refresh token), #1287 (both Web and OAuth paths lack working refresh), #108 (repeated keychain prompts for Claude Code-credentials), #1681 (malware-like perception of keychain behavior).

Workaround for affected users

Quit CodexBar. (Disabling the Claude provider via providers[].enabled=false in ~/.config/codexbar/config.json is being tested as a lighter workaround; I can report back in a comment.)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 2, 2026, 10:02 AM ET / 14:02 UTC.

Summary
Keep open: current main still expects a claudeAiOauth OAuth block in Claude credentials and still has a source-covered experimental security-CLI path that can attempt delegated Claude refresh from the background, while this report adds current Claude Code 2.1.x evidence that the keychain item now contains only mcpOAuth plus browser-launch impact.

Reproducibility: no. high-confidence live reproduction was run in this environment because AGENTS.md forbids live Claude/Keychain probes that can trigger prompts. Source and tests do provide a clear current-main path for background delegated refresh under the experimental security-CLI reader, and the reporter supplied detailed logs and keychain-shape evidence.

Root-cause cluster
Relationship: canonical
Canonical: #1844
Summary: This issue is the richest current report for the Claude Code 2.1.x mcpOAuth keychain shape plus background delegated-refresh browser launch; older related reports cover overlapping refresh/keychain symptoms but lack this concrete storage-change evidence.

Members:

• same_root_cause: Claude constantly looses token for access #1823 - It reports the same delegated-refresh failure string, but lacks the current Claude Code 2.1.x mcpOAuth-only keychain and browser-launch evidence.
• partial_overlap: Claude session repeatedly shows "Unauthorized. Your Claude session may have expired." — both Web and OAuth paths lack working refresh #1287 - It covered broader Claude OAuth/Web refresh failures and misleading auth errors, but predates the specific Claude Code 2.1.x keychain-shape report.
• partial_overlap: [Bug]: CodexBar can desync Claude Code's OAuth refresh token, forcing daily re-login #1161 - It concerns Claude CLI OAuth token ownership and refresh behavior, which constrains the fix, but its reported failure mode was refresh-token desynchronization rather than browser launches.
• adjacent_distinct: Clarify macOS Keychain/password prompts so new users do not confuse CodexBar with malware #1681 - It covers malware-like Keychain trust perception, which is relevant to impact, but it is a broader UX/security explanation issue rather than this credential-store regression.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

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

Next step
Manual maintainer auth/security review is needed because the fix depends on Claude Code's new credential storage and a policy decision for background repair behavior.

Security
Needs attention: This issue is security-sensitive because the failure path involves OAuth credential storage, Keychain reads, and background browser-launch behavior.

Review details

Best possible solution:

Confirm Claude Code 2.1.x's actual OAuth storage, then make background refresh fail closed without launching Claude/browser while offering an explicit user-click re-auth repair path with regression tests for both keychain readers.

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

No high-confidence live reproduction was run in this environment because AGENTS.md forbids live Claude/Keychain probes that can trigger prompts. Source and tests do provide a clear current-main path for background delegated refresh under the experimental security-CLI reader, and the reporter supplied detailed logs and keychain-shape evidence.

Is this the best way to solve the issue?

Unclear; the narrow maintainable direction is to discover the new Claude Code credential source and block background browser-opening repair, not to parse mcpOAuth as Claude auth or direct-refresh Claude CLI-owned tokens speculatively.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The new Claude Code 2.1.x primary OAuth storage location is not established from source, so a fix needs maintainer or reporter confirmation before broadening credential discovery.
• The reported browser launch depends on Claude CLI behavior during /status; source confirms CodexBar invokes that path, but this review did not run live Keychain or Claude probes because repository policy forbids prompt-triggering validation without explicit request.
• Any repair touches OAuth credentials, Keychain behavior, and user privacy, so it needs maintainer security/product review before automation changes the auth boundary.

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

Label changes

Label changes:

• add P1: This is a fresh Claude provider auth regression report with current-version evidence and disruptive background browser launches for affected users.
• add impact:security: The failure path involves OAuth credentials, Keychain access, and malware-like background browser launches, all of which require security-sensitive handling.
• add impact:auth-provider: The issue is directly about Claude OAuth credential discovery, delegated refresh, and provider auth routing.
• 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:

• P1: This is a fresh Claude provider auth regression report with current-version evidence and disruptive background browser launches for affected users.
• impact:auth-provider: The issue is directly about Claude OAuth credential discovery, delegated refresh, and provider auth routing.
• impact:security: The failure path involves OAuth credentials, Keychain access, and malware-like background browser launches, all of which require security-sensitive handling.

Evidence reviewed

Security concerns:

• [medium] Gate browser-opening auth repair behind user action — Sources/CodexBarCore/Providers/Claude/ClaudeStatusProbe.swift:289
  The delegated repair path invokes Claude /status from background OAuth refresh, and the reporter's evidence shows that can open the default browser through Claude CLI recovery.
  Confidence: 0.82
• [medium] Keep diagnostics redacted
  Follow-up should ask for redacted keychain shape, versions, and logs only; raw OAuth tokens, cookie headers, Authorization values, and full Keychain payloads should not be posted.
  Confidence: 0.88

What I checked:

• Repository policy read: AGENTS.md was read fully; its no-live-Keychain/provider-probe instruction constrained this review to source, tests, docs, and history rather than real Claude or Keychain commands. (AGENTS.md:1, 0a18391e1838)
• Credential parser still requires claudeAiOauth: Current main decodes only Root.claudeAiOauth and throws missingOAuth when that top-level block is absent, so an mcpOAuth-only payload is not supported by this parser. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentialModels.swift:90, 0a18391e1838)
• Security CLI fallback matches the reported log: The security CLI reader logs Claude keychain security CLI output invalid; falling back with parse error metadata when /usr/bin/security returns payloads that the OAuth parser cannot parse. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials+SecurityCLIReader.swift:96, 0a18391e1838)
• Delegated refresh path remains on main: Expired CLI-owned credentials still reach attemptDelegatedRefresh, which calls the Claude CLI /status touch path; that is the background path implicated by the browser-launch report. (Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift:371, 0a18391e1838)
• CLI touch implementation: The delegated repair touch runs Claude /status through ClaudeCLISession.shared.capture, which is an external Claude CLI invocation rather than a purely local parser operation. (Sources/CodexBarCore/Providers/Claude/ClaudeStatusProbe.swift:277, 0a18391e1838)
• Regression test preserves the risky background behavior: A current test named oauth delegated retry experimental background ignores only on user action suppression uses .securityCLIExperimental, background interaction, and allowBackgroundDelegatedRefresh: false, then expects one delegated refresh attempt. (Tests/CodexBarTests/ClaudeUsageTests.swift:1415, 0a18391e1838)

Likely related people:

• steipete: Recent current-main commits and the merged CLI OAuth isolation pull request changed Claude OAuth CLI isolation, prompt policy tests, and adjacent auth behavior. (role: recent area contributor and reviewer; confidence: high; commits: c57de22c9ffe, 92bbb7a67073, 24490b6434d4; files: Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift, Sources/CodexBarCore/Providers/Claude/ClaudeProviderDescriptor.swift, Tests/CodexBarTests/ClaudeUsageTests.swift)
• Ratul Sarna: Git history ties the delegated OAuth refresh coordinator, experimental security reader, and prompt-policy behavior to this contributor's earlier commits. (role: feature-history contributor; confidence: high; commits: fa7256fda7ba, b2ef621d5fef, 97a81a4bdf10; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthDelegatedRefreshCoordinator.swift, Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials+SecurityCLIReader.swift, Sources/CodexBarCore/Providers/Claude/ClaudeUsageFetcher.swift)
• Rajvardhan Patil: History search for CLI storage ownership points to the commit that preserves Claude CLI token ownership, which is central to the current delegated-refresh path. (role: introduced token-ownership policy; confidence: medium; commits: 3488587856c7; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, Tests/CodexBarTests/ClaudeOAuthCredentialsStoreCLIStorageOwnershipTests.swift)
• derekszen: The merged Claude OAuth CLI isolation work is relevant to whether OAuth refresh paths may launch Claude subprocesses in different runtimes. (role: adjacent runtime-boundary contributor; confidence: medium; commits: 3bc978114747; 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.

[mira-semera]

Follow-up on the workaround: setting providers[].enabled=false for claude directly in ~/.config/codexbar/config.json (with the app restarted) does stop the hourly delegated refresh and the browser launches — verified over 80+ minutes of runtime (zero open calls, zero ClaudeOAuthCredentialsError log entries, the expected ~64-min tick did not fire). Codex/Antigravity tracking keeps working.

One possibly related note: toggling the Claude provider in the Settings UI did not appear to persist this state for me earlier (the config still had "enabled": true afterwards), which is why the refresh seemed to survive "disabling" the provider. Editing config.json directly worked.