fix: confirm Codex weekly reset with zero available credits - #2897
Merged
steipete merged 1 commit intoAug 13, 2026
Merged
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
clawsweeper
Bot
added
merge-risk: 🚨 compatibility
|
Codex review: needs real behavior proof before merge. Reviewed August 13, 2026, 2:01 AM ET / 06:01 UTC. ClawSweeper reviewWhat this changesThe PR permits two matching early Codex weekly-reset observations when the prior reset-credit inventory explicitly contained zero available credits, with a focused regression test. Regression provenancePossible regression — probable (reproduction; reviewed change). No predecessor PR is attributed. Merge readiness⛔ Blocked until real behavior proof from a real setup is added - 7 items remain Keep open: the reported zero-credit path is a concrete current-main defect, but the proposed bypass also accepts later inventories with available credits and needs a narrow safeguard plus after-fix real behavior proof. Priority: P2 Review scores
Verification
How this fits togetherCodexBar fetches Codex quota snapshots and confirms suspicious early weekly resets before updating the menu-bar usage. The confirmation guard compares prior, initial, and follow-up quota and reset-credit observations before publishing or retaining the current display. flowchart LR
A[Prior Codex snapshot] --> D[Reset confirmation guard]
B[Initial quota refresh] --> D
C[Follow-up quota refresh] --> D
D --> E{Reset evidence accepted?}
E -->|yes| F[Publish fresh menu-bar usage]
E -->|no| G[Keep prior usage]
Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Accept the server-side zero-credit case only when every confirmation inventory explicitly remains unavailable, cover a later-available-credit counterexample, and provide a redacted after-fix refresh trace. Do we have a high-confidence way to reproduce the issue? Yes—current source deterministically preserves the supplied all-zero sequence because an empty prior available inventory returns false; the submitted focused test encodes the same path, though this read-only review did not execute it. Is this the best way to solve the issue? No—the intended narrow exception is reasonable, but it must also constrain the initial and confirmation inventories so an available later credit cannot bypass the existing consumption safeguard. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 208016687098. LabelsLabel changes:
Label justifications:
EvidenceAcceptance criteria:
What I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
CodexBar can get stuck showing a stale weekly usage percentage forever when a Codex weekly quota reset is observed before the previous reset boundary and the account has zero available reset credits (
availableCount == 0).CodexWeeklyResetConfirmation.confirmationDecisionrequires proof that a manual reset credit was consumed (confirmsManualResetCreditConsumption). That proof can never hold when the previous snapshot explicitly reported an empty reset-credit inventory, so every refresh re-evaluates to.preservePreviousand the fresh value is never published.This changes
confirmsManualResetCreditConsumptionso an explicitly observed zero-credit inventory (previousCredits.availableCount == 0) trusts the two consistent observations (initial + confirmation) that are the only signal a server-side early reset has. Anil/unknown previous inventory stays conservative and still demands consumption proof, so the existing false-positive protection (transient low readings, missing/expired credits) is unchanged.Changes
Sources/CodexBar/Providers/Codex/CodexWeeklyResetConfirmation.swift: when the previous snapshot has an explicitly known-zero credit inventory, returntruefromconfirmsManualResetCreditConsumptioninstead of deadlocking.Tests/CodexBarTests/CodexWeeklyResetConfirmationTests.swift: new testzero available reset credits confirm a server-side early weekly reset by observationreproducing the live failure (98% → 1%, boundary 8/18 → 8/20, zero credits).Repro
codexResetCredits.availableCount == 0,credits == []).confirmationDecisionreturned.preservePreviousindefinitely → status-bar icon stuck at the old value.Verification
CodexWeeklyResetConfirmationTests: 20/20 pass (including the new case; existing conservative cases like "one missing reset credit inventory does not confirm" and "expired omitted reset credit does not confirm" still pass).swift build --target CodexBarCorepasses.make check(swiftformat + swiftlint --strict): 0 violations.Related