Repository navigation
Codex GUI blocks prompt submission at 100% usage, including with other models #5797
Description
Activity
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
edited
Related to #5694 / #4878 — distinguish the version and Reserve state
This is the same observed Desktop submission-gating symptom family as #5694: the desktop account is exhausted, selecting another model does not enable Send, and the reporter describes recovery after quota reset or an account change. It is not yet a demonstrated provider-side HTTP 429 or proof that the selected model uses an independently authorized upstream.
#4878 records a more specific state: regular and Luna Reserve allowances are both exhausted; the model picker reopens, but Send stays disabled. Reserve status is not given here, so please link the reports without assuming that this exact transition or a shared internal cause has been reproduced.
Important version distinction: this report explicitly names OpenCodex 2.64.0 and Codex App 26.917.71314 on Windows. In the closure comment on #5694, the maintainer identifies 2.65.0 as the release intended to ship the default-on 98% main-account guard from #5743, with the #5748 follow-up. #5743 changes an existing opt-in 99% policy to default-on at 98%. Thus the suggested pre-exhaustion cutoff already has related implementation work; this 2.64.0 report alone is not evidence that the new default failed after installation. Please record the actually running OpenCodex version and effective guard state separately from the Desktop version.
The cutoff is prevention, not recovery: stopping guarded main-account requests before exhaustion does not replenish an account already at 100% or establish that an already-disabled composer will recover. The merged policy explicitly uses observed quota rather than reserving remaining capacity. Traffic outside that guarded path can still consume the same account. A working preventive guard and a remaining post-exhaustion composer problem can therefore coexist.
To connect this Windows report to the existing investigation, the remaining useful evidence is a short redacted summary: the effective provider/auth mode (independent provider vs the same ChatGPT allowance), regular/Reserve availability, effective guard state and whether it was active before exhaustion, and whether an attempted submission reaches the app-server/OpenCodex at all. No credentials, account/thread identifiers, raw prompts or full usage/configuration dumps are needed; no need to deliberately exhaust another account.
The Windows/App-version details are valuable corroboration. Retain recovery at already-exhausted quota as a separate verification case rather than closing it solely on the existence of a pre-exhaustion cutoff. This comment adds cross-issue/version context, not a new local reproduction or a verified workaround for this installation.
This is addressed in v2.65.0.
OpenCodex now stops routing requests to the main Codex account at 98% usage, before the upstream account reaches 100% and the Codex App disables the Send button. The lock is on by default:
- fix(codex): bundle L4 — service uninstall key, startup rollout budget, sub-agent identity, agent-message recovery, 98% main lock #5743 lowered the main-account hard lock threshold to 98% (
MAIN_ACCOUNT_HARD_LOCK_PERCENT = 98). - Codex send button grayed out of after 0% usage #5694 made the lock default-on. It is disabled only if
codexMainAccountHardLock: falseis explicitly saved in the config.
To pick it up, update with
npm install -g @bitkyc08/opencodex@latest(or the desktop app updater) and restart the proxy. If you previously turned the lock off, re-enable it in the dashboard or removecodexMainAccountHardLock: falsefrom your config.If the Send button still becomes disabled on v2.65.0 or later, please reopen this issue with your version and the usage percentage at the time. A configurable threshold is tracked separately in #5649.
Reacted by ratu.sh- fix(codex): bundle L4 — service uninstall key, startup rollout budget, sub-agent identity, agent-message recovery, 98% main lock #5743 lowered the main-account hard lock threshold to 98% (
98%-safeguard not works. Codex bypass it and derive usage to 100%.
- added a commit that references this issue
on Sep 26, 2026
Client or integration
Codex App
Area
Authentication and account pool
Summary
When Codex usage reaches 100%, the Codex GUI disables the prompt submission button. The conversation cannot be continued through the GUI, even after switching to another model. This behavior appeared after a recent update.
Expected behavior
Reaching the Codex model usage limit should not prevent prompt submission with a model that remains available.
Actual behavior
The submit button is disabled for all models. Prompt submission becomes available again only after the usage limit resets. Signing in with another account also restores access.
Suggested improvement
Consider stopping requests to Codex models before usage reaches 100% (for example, at 99%) if that would keep the GUI available for other models.
Environment
26.917.71314Reproduction
ocx start.Version
2.64.0
Operating system
Windows 26H1, build `28000.3086
Provider and model
Any
Logs or error output
Screenshots and supporting files
Redacted configuration
//opencodexChecks