Claude OAuth：0.60.3 中选择“始终允许”并添加钥匙串授权后，仍反复索要密码

[ttoswar]

问题描述

使用 Claude Code CLI，并在 CodexBar 中通过 OAuth API 获取 5 小时／每周用量。已经在 macOS 钥匙串授权窗口选择过“始终允许”，也曾手动将 CodexBar 加入 Claude Code-credentials 的允许访问列表，但之后仍反复出现同一凭据的密码授权窗口。

希望确认：这是当前版本已知的 Claude 凭据更新／访问控制问题，还是还需要检查应用签名或其他授权条件？“始终允许”无法持续生效的原因及处理办法，目前对用户不够清楚。

环境与设置

• CodexBar：0.60.3（146），安装位置 /Applications/CodexBar.app。
• macOS：27.0（26A428），Apple silicon。
• Claude Code：最初排查时为 2.1.274；复发时未重新核验 CLI 版本。
• 日常只使用 Claude Code CLI；CodexBar 用量来源选择 OAuth API。
• Allow reading Claude Code's credentials：开启。
• 钥匙串提示策略：always（界面“始终允许提示”）。
• debugDisableKeychainAccess：false。
• 刷新策略：adaptiveAgentAware。

实际经过与验证

1. 2026-09-17，CodexBar 显示 Claude OAuth credentials not found. Run claude to authenticate.。
2. Claude CLI 已登录，Claude Code-credentials 条目实际存在。使用现有令牌直接请求官方 OAuth 用量接口返回 HTTP 200；令牌未输出或保存到文件。
3. CodexBar bundled CLI 的诊断日志显示：Keychain preflight requires interaction for the current process。
4. 当时钥匙串允许访问列表只有系统 security 工具。经授权，仅将 /Applications/CodexBar.app 添加到该条目的允许列表并保存。
5. 随后在 CodexBar 内手动刷新成功：来源显示 OAuth，5 小时和每周剩余额度正常出现，原错误消失。
6. 2026-09-21，用户再次遇到反复索要密码的系统窗口：CodexBar 想访问钥匙串中的 Claude Code-credentials，提供“始终允许／拒绝／允许”按钮。
7. 当天检查发现该凭据修改时间为 10:50；检查时允许访问列表中仍显示 security 和 CodexBar，“询问钥匙串密码”未勾选。因此不能据此断言检查当时 CodexBar 已从列表消失，也未捕获到 ACL 改写前后的完整证据。

复发发生在继续日常使用 Claude Code 之后；尚未确定精确触发动作和每次发生的时间间隔。

预期结果

在用户已经授权后，尽可能持续正常刷新。如果 Claude Code 的凭据生命周期使“始终允许”无法持久生效，希望 CodexBar 能明确解释限制并给出可靠的恢复方式，避免让用户反复输入密码却以为已经永久解决。

可能原因与待确认点

0.60.3 的源码注释说明：Claude Code 在刷新令牌时会重写其钥匙串条目并替换 ACL，使授予 CodexBar 的权限可能是临时的，导致重复密码弹窗。

这与现象相符，但本次并未证明每次弹窗都是 ACL 被覆盖引起的；也未完成运行中应用与 ACL 内代码签名要求的比对。希望维护者协助区分凭据重写、签名／路径不匹配或其他原因。

另外，“始终允许提示”与 macOS 的“始终允许”含义不同，容易混淆。改成“仅在用户操作时提示”可以减少后台打扰，但可能让用量在需要重新授权时停止更新，不能算完整解决。

相关报告

• Keychain password prompt repeats every few hours despite 'Always Allow' #340：选择 Always Allow 后仍反复弹窗，已关闭。
• Claude Keychain prompt recurs every token refresh when the Claude Code-credentials trusted-app ACL names a different bundle path than the running app #2884：记录了路径／授权持久化相关的类似现象，已关闭；本报告尚未证明是相同根因。
• Claude usage stops updating on 0.47.0; refresh fails with SessionError #2634：Claude OAuth 凭据读取问题，已关闭。
• Stop direct Claude Keychain reads and route owner CLI by profile #2380：涉及停止直接读取 Claude 拥有的钥匙串凭据及其 ACL 生命周期。

本报告未附密码、令牌、账号邮箱或原始钥匙串内容。

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 20, 2026, 11:23 PM ET / September 21, 2026, 03:23 UTC.

Summary
Keep open under the repository’s conservative review policy. Current main and v0.63.0 retain the consented credential-reading path, so an upgrade is not a demonstrated cure. The report carefully distinguishes observed recurring prompts from an unproven ACL or signing cause.

Reproducibility: no. high-confidence current-main reproduction is established: the report documents recurrence on 0.60.3, but lacks a repeatable trigger and evidence distinguishing ACL replacement from executable authorization failure.

Ways to help us reproduce this

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

Next step
No bounded repair is established; request current-release recurrence details, the initiating action, and a redacted prompt identifying the requester, using the existing safe troubleshooting guidance without dumping credentials.

Review details

Best possible solution:

Preserve explicit consent and use the existing recovery UI to explain temporary grants and offer CLI/Web alternatives without promising permanent macOS authorization.

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

No high-confidence current-main reproduction is established: the report documents recurrence on 0.60.3, but lacks a repeatable trigger and evidence distinguishing ACL replacement from executable authorization failure.

Is this the best way to solve the issue?

Unclear until the cause is isolated. Existing documentation and CLI/Web options address recovery; changing credential ownership or overriding prompt preferences would be premature.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The precise cause remains unverified: the report does not distinguish credential-item replacement from executable authorization mismatch or another macOS authorization condition.

Codex review notes: model internal, reasoning medium; reviewed against 9d3f6bf5499a.

Label changes

Label changes:

• add P2: Repeated authorization interrupts an opted-in Claude usage workflow, but a current core outage or deterministic regression is not established.
• add impact:auth-provider: The report concerns access to Claude OAuth credentials and recovery of usage fetching.
• add impact:ux-friction: Repeated password prompts and two different meanings of “Always Allow” create avoidable confusion despite available source and prompt controls.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.

Label justifications:

• P2: Repeated authorization interrupts an opted-in Claude usage workflow, but a current core outage or deterministic regression is not established.
• impact:auth-provider: The report concerns access to Claude OAuth credentials and recovery of usage fetching.
• impact:ux-friction: Repeated password prompts and two different meanings of “Always Allow” create avoidable confusion despite available source and prompt controls.

Evidence reviewed

What I checked:

• Reported configuration and uncertainty: The reporter identifies CodexBar 0.60.3, explicit direct-read consent, and the always-prompt policy. Manual authorization previously restored usage, but the recurrence lacks a precise trigger or before/after ACL and executable-identity comparison. The bundled CLI diagnostic does not by itself establish the GUI process’s authorization state.
• Current consent and prompting contract: Direct reads remain consent-gated, with an explicit warning that Claude-owned item replacement can invalidate grants. The always policy permits access independently of whether the refresh is user initiated. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift:2994, 9d3f6bf5499a)
• Authorization diagnosis is not path-only: Preflight inspects metadata without requesting secret data and validates stored trusted-application requirements. Rejection produces the reported current-process interaction message; a displayed CodexBar entry in Keychain Access alone does not establish successful validation. (Sources/CodexBarCore/KeychainAccessPreflight.swift:250, 9d3f6bf5499a)
• Existing explanation and safer alternatives: Documentation already distinguishes executable signing requirements from install paths and explains foreign-item rotation. It recommends avoiding broad grants and offers Claude CLI/Web alternatives; the app’s authorization pre-alert already includes a Learn More link. (docs/keychain-prompts.md:44, 9d3f6bf5499a)
• Latest release retains the relevant behavior: GitHub identifies v0.63.0, published September 20, as the latest release. Its credential store still contains the temporary-grant warning and consent-gated direct read; this is not evidence of a shipped fix for the recurrence. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift:2991, f3e718c897d5)
• Established owner decision: The owner explicitly approved consented direct reads alongside CLI fallback at Claude usage stops updating on 0.47.0; refresh fails with SessionError #2634 (comment). History records that implementation in commit 0954a74; restoring an unconditional foreign-read prohibition would contradict that decision. (Sources/CodexBarCore/Providers/Claude/ClaudeOAuth/ClaudeOAuthCredentials.swift, 0954a74a0b9d)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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]

CodexBar’s “Always allow prompts” permits future prompts; macOS “Always Allow” grants access to the current item and signing identity. Claude Code can recreate the item, and a visible CodexBar ACL entry does not prove its signing requirement matches the running app. PR #3816 clarifies this and hardens an experimental helper, but does not establish your recurrence’s cause. “Only on user action” reduces background interruptions and may require manual Refresh. A redacted trace identifying the requesting executable and triggering action would help; no credential values are needed.

CodexBar 的“始终允许提示”表示允许再次弹窗；macOS 的“始终允许”仅授权当前条目和代码签名身份。Claude Code 重建条目可能重置授权，即使 ACL 仍显示 CodexBar，也不能证明签名要求匹配。PR #3816 补充说明并加固实验性读取器，但尚未确认本次复发原因。“仅在用户操作时提示”可减少后台打扰，但可能需要手动刷新。建议继续保留此报告，并提供已脱敏的请求进程路径和触发操作；无需提供任何凭据内容。