Stop background Claude keychain discovery

[m-rokai]

Summary

• prevent background MCP-only credential discovery from reading Claude Code-credentials through Security.framework when the prompt policy is onlyOnUserAction
• preserve MCP-only detection for explicit user refreshes and the opt-in always policy
• add regression coverage for both interaction modes

Root cause

The MCP-only payload detector bypassed the normal Claude prompt-policy gate and issued a Security.framework “no UI” read during background availability checks. Legacy Keychain ACLs can still display the macOS password dialog for these reads, causing recurring prompts even though the call was marked non-interactive.

Fixes #2115.

User impact

Background refreshes no longer touch the Claude Code Keychain item under the default onlyOnUserAction policy. Explicit refreshes can still inspect it when needed.

Validation

• swift test --filter ClaudeOAuthCredentialsStoreMCPOnlyGuardTests
• make check
• make test (blocked by an unrelated current-main AdaptiveRefreshTimerTests baseline failure: “manual mode performs the initial refresh but no recurring ticks” observes 2 refreshes instead of 1; reproduced when running that suite alone)

No live Keychain read was used for validation.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 13, 2026, 8:35 PM ET / July 14, 2026, 00:35 UTC.

Summary
The PR prevents background Security.framework MCP-only Claude credential discovery under the user-action-only prompt policy while preserving user-initiated and always-allowed discovery, with focused regression coverage.

Reproducibility: no. there is not yet a high-confidence live reproduction in the PR. The linked screenshot and current source identify a credible background Security.framework path, but the contributor explicitly avoided a real Keychain read and supplied no affected-Mac before/after proof.

Review metrics: none identified.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #2115
Summary: This PR explicitly targets the recurring background Claude Keychain prompt reported by the linked open issue and is its candidate fix.

Members:

• canonical: Constantly reoccuring keychain prompt for "Claude Code-credentials" #2115 - The issue contains the affected-version report and visible password-dialog symptom that this PR claims to fix.

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

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Provide redacted affected-Mac proof showing background refresh stays prompt-free and explicit Refresh still works under the user-action-only policy.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR has synthetic Keychain tests but no after-fix evidence from an affected Mac; add a redacted screen recording, runtime logs, or terminal transcript, update the PR body to trigger review, or ask a maintainer to comment @clawsweeper re-review.

Risk before merge

• [P1] The change alters Claude credential discovery and provider availability behavior in background contexts; without an affected-Mac run, maintainers cannot confirm that recurring legacy ACL dialogs stop while explicit Refresh and opt-in always discovery continue to work.

Maintainer options:

1. Require affected-Mac proof (recommended)
   Ask for a redacted recording, logs, or live validation transcript showing a background refresh without a password dialog followed by a successful explicit Refresh.
2. Accept the unproven runtime risk
   Merge based on source reasoning and synthetic coverage while accepting that legacy Keychain ACL behavior and Claude source selection remain unverified on real hardware.

Next step before merge

• [P1] The remaining blocker is contributor-supplied proof from an affected macOS Keychain setup, not a concrete code repair that an automated worker can safely produce.

Security
Cleared: The diff narrows background access to an existing credential item, adds no dependency or executable supply-chain surface, and preserves explicit access paths.

Review details

Best possible solution:

Land the interaction-aware guard after a redacted affected-Mac recording or runtime transcript shows background refresh remains prompt-free and an explicit Refresh still discovers the MCP-only credential under the same configuration.

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

No, there is not yet a high-confidence live reproduction in the PR. The linked screenshot and current source identify a credible background Security.framework path, but the contributor explicitly avoided a real Keychain read and supplied no affected-Mac before/after proof.

Is this the best way to solve the issue?

Yes, provisionally: gating the MCP-only detector immediately before the Security.framework read is the narrowest way to honor the existing interaction policy while preserving explicit and opt-in discovery. Real macOS proof is still required before merge.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• remove rating: 🧂 unranked krab: Current PR rating is rating: 🦪 silver shellfish, so this older rating label is no longer current.

Label justifications:

• P2: This is a bounded Claude Keychain prompt regression affecting existing users, with a narrow proposed fix but no evidence of broader application failure.
• merge-risk: 🚨 auth-provider: The PR changes when Claude credentials are read and detected, so a runtime mistake could affect OAuth availability or provider routing despite green focused tests.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR has synthetic Keychain tests but no after-fix evidence from an affected Mac; add a redacted screen recording, runtime logs, or terminal transcript, update the PR body to trigger review, or ask a maintainer to comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Prompt-policy gate: The proposed guard returns before reading the Claude Code Keychain item when Security.framework is used in a non-user-initiated context and the effective policy is onlyOnUserAction; the user-initiated and always modes remain available. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials+SecurityCLIReader.swift:360, 7b02b705fa09)
• Focused regression coverage: The test changes assert that background discovery is skipped while an explicit user refresh still detects the synthetic MCP-only payload, with additional coverage retaining the opt-in always behavior. (Tests/CodexBarTests/ClaudeOAuthCredentialsStoreMCPOnlyGuardTests.swift:37, 7b02b705fa09)
• Established behavior contract: The released Claude OAuth documentation states that Auto-mode background refresh suppresses prompts and limits interactive prompts to menu opens or manual refreshes, making the linked recurring background prompt a bug rather than a new policy choice. (CHANGELOG.md:100, 315ff65f7b2a)
• Linked current-version report: The canonical linked issue reports recurring Claude Code-credentials password dialogs on CodexBar v0.42.1 even without active menu interaction, matching the code path targeted by this PR.
• Missing real behavior proof: The PR explicitly states that no live Keychain read was used for validation; focused tests and CI cannot prove that legacy macOS Keychain ACL dialogs stop appearing or that explicit Refresh still works on an affected Mac. (7b02b705fa09)
• Feature-history provenance: Repository release history credits @manikv12 across the earlier Claude OAuth and Keychain prompt-policy series, including the work that introduced background suppression and the user-action-only policy. (CHANGELOG.md:100, 315ff65f7b2a)

Likely related people:

• manikv12: The repository changelog credits this contributor for the earlier Claude OAuth and Keychain prompt-policy series that established background suppression, interaction gating, and deterministic failure behavior. (role: feature-history owner; confidence: high; files: Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials+SecurityCLIReader.swift, Tests/CodexBarTests/ClaudeOAuthCredentialsStoreMCPOnlyGuardTests.swift)
• steipete: As the repository owner associated with the released Claude OAuth/Keychain policy series, this person is a likely reviewer for credential-discovery and macOS prompt behavior changes. (role: adjacent owner and merger; confidence: medium; files: CHANGELOG.md, Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials+SecurityCLIReader.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

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.

Review history (2 earlier review cycles)

• reviewed 2026-07-13T23:59:44.463Z sha 7b02b70 :: needs real behavior proof before merge. :: none
• reviewed 2026-07-14T00:18:10.755Z sha 7b02b70 :: needs real behavior proof before merge. :: none