Repository navigation
Conversation
…d lock (#6845) The main-account hard lock and the credits switch were independent by design: with the lock on, a main login holding spendable ChatGPT credits was still refused before any upstream send, and 'ocx account credits openai main on' could not change that. #6845 reports exactly this 429 while the official Codex client spends the same credits. Add codexMainAccountCreditsOverrideHardLock (default off). When on, a blocked main account whose credits are opted in and freshly observed as spendable is treated as usable by both selection (codexAccountUnusableReason) and admission (assertMainAccountPolicy), so the request reaches upstream and the overage draws credits. The release is only as fresh as the credit observation; a stale or refused balance re-arms the lock. Default behavior is unchanged and the existing 'allowing credits does not lift the main lock' test still passes. Wired through the settings API and 'ocx system settings --main-account-credits-override-hardlock'.
Adds a second switch to the main-account protection card, beside the lock switch, wired to codexMainAccountCreditsOverrideHardLock. Off by default. It shares the card's single /api/settings read and PUT, so the existing read-count and focus contracts are unchanged; the four new locale keys ship in all eleven catalogs (zh-TW translated, not an English placeholder).
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: true
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
⏳ DRAFT
What to do
Review readiness checklist
0/4 boxes ticked. This pull request was already a draft. Its draft status will be preserved after every issue above is resolved. |
|
Withdrawing — the credits-before-exhaustion premise doesn't hold upstream. |
Summary
Fixes #6845.
The main-account hard lock (#6363) and the credits switch are independent by design, so a hard-locked main account that still holds spendable ChatGPT credits is refused before any upstream send — the reported local 429 returned within 3–23 ms — even with "Use credits" on. The only workaround is disabling the lock entirely.
This adds an opt-in
codexMainAccountCreditsOverrideHardLock(default off). When on, a blocked main account whose credits are consented and freshly observed as spendable is treated as usable by both selection (codexAccountUnusableReason) and admission (assertMainAccountPolicy), so the request reaches upstream and the overage draws credits. The release is only as fresh as the credit observation; a spent, refused, or stale balance re-arms the lock.ocx system settings --main-account-credits-override-hardlock on|off.Verification
bun run typecheck, GUItsc -b,bun run lint:i18n, GUIbun run build,bun run structure:check,bun run privacy:scan— pass.tests/codex-integration/codex-credits-after-limit-main.test.ts(4 new), adjacent credit/hard-lock suites (270 pass), GUImain-account-hard-lock-setting.test.tsx(2 new) + locale parity.Checklist
Review readiness checklist
This PR stays in draft until every box below is ticked. Tick all four boxes once the requirements are met:
Required local validation passed; commands, results, and any full-suite exception are documented.
I pushed my PR to a recent dev commit (at most 10 behind; a maintainer may still ask for the exact tip before merge).
I resolved all correct Codex and CodeRabbit findings.
My PR is ready for review.