Show Claude prepaid balance - #2443
Conversation
7111416 to
ea9d6b4
Compare
|
Codex review: needs changes before merge. Reviewed July 25, 2026, 12:53 PM ET / 16:53 UTC. ClawSweeper reviewWhat this changesThe PR fetches Claude prepaid Usage-credit balances from Claude web endpoints, merges a matched balance into Claude OAuth or CLI usage data, and renders it in the menu bar and CLI output. Merge readinessThis PR adds a useful Claude balance view and includes a menu screenshot, but the current automatic web-enrichment path still appears able to delay an otherwise successful OAuth or CLI refresh while importing browser cookies. That conflicts with the repository’s cookie-import guidance and needs a narrow guard plus regression coverage before merge. Priority: P2 Review scores
Verification
How this fits togetherCodexBar gathers Claude usage from OAuth, the Claude CLI, and optional Claude web-session data. This change adds a prepaid-balance enrichment step before the merged usage snapshot is rendered in the menu card, provider details, and CLI. flowchart LR
A[Claude OAuth or CLI usage] --> C[Claude usage snapshot]
B[Optional Claude web session] --> D[Prepaid balance request]
D --> E[Account identity match]
C --> E
E --> F[Merged Claude usage]
F --> G[Menu bar card]
F --> H[CLI output]
Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Copy recommended automerge instructionTechnical reviewBest possible solution: Keep the existing OAuth and CLI refresh result as the default fast path; enrich it with prepaid balance only from a manual or already cached Claude web session, or behind an explicit browser-import opt-in, with coverage for both the compatible default and the opt-in path. Do we have a high-confidence way to reproduce the issue? No live high-confidence reproduction was established in this read-only review. The source and the prior concrete review note provide a medium-confidence source reproduction: use the automatic Claude cookie source with optional usage enabled, no cached usable cookie, and web extras disabled, then refresh OAuth or CLI usage. Is this the best way to solve the issue? No. The separate balance field and identity match are reasonable, but automatic cookie import should not become a prerequisite or delay source for an existing OAuth or CLI refresh; cached/manual-only enrichment or an explicit opt-in is safer. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against cc8da27cec92. LabelsLabel changes:
Label justifications:
EvidenceAcceptance criteria:
What I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (1 earlier review cycle)
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 216d9973d2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let includePrepaidBalance = context.runtime == .app && | ||
| context.includeOptionalUsage && | ||
| webEnrichmentAccess.isAvailable |
There was a problem hiding this comment.
Avoid blocking OAuth refreshes on automatic cookie import
With the default app settings (showOptionalCreditsAndExtraUsage enabled and Claude cookie source .auto), this makes every successful OAuth/Auto refresh await applyWebExtrasIfNeeded, even when web extras are disabled. That path invokes the generic browser-cookie importer and can wait for the 60-second context.webTimeout; therefore, when no cached Claude cookie exists or browser database/Keychain access stalls, an already-completed OAuth result is delayed and non-Chrome browsers may be probed or prompt. Restrict balance enrichment to cached/manual sessions or an explicit browser-import opt-in.
AGENTS.md reference: AGENTS.md:L48-L48
Useful? React with 👍 / 👎.
|
Merged after full verification, with the owner-approved access contract enforced: prepaid-balance web enrichment uses only an already-cached or manually-configured web session — Auto can never initiate browser-cookie discovery during ordinary OAuth/CLI refresh, and a no-cache regression pins that (primary results publish undelayed). Identity matching keeps balances scoped to the matching Claude account. Focused suite 22/22; exact-head CI fully green after one unrelated temp-file-race rerun (https://github.com/steipete/CodexBar/actions/runs/30392441349). Autoreview clean. Thanks @Zihao-Qi! |
Summary
Why
CodexBar could show Claude Extra usage spent/cap values but not the remaining prepaid balance. Claude exposes that balance separately in minor currency units, so this adds the missing field without treating it as another quota denominator.
Related: #975.
Validation
swift test --filter 'ClaudeWebCookieRenewalTests|ClaudeOAuthFetchStrategyAvailabilityTests|ClaudeOAuthTests|ClaudeWebFetchDeadlineTests|ClaudeWebUsageExtraWindowTests|ClaudeProviderImplementationTests|CLIOutputTests|ClaudeMenuCardCostTests|MenuCardHeightFingerprintTests|PreferencesPaneSmokeTests'— 136 tests passed across 11 suitesswift test --filter 'ClaudeMenuCardCostTests|ClaudeProviderImplementationTests'— 6 tests passed across 2 suitesmake checkmake test— stopped in three Keychain credential-store suites not modified by this PR; the focused feature tests pass separatelyScreenshot