Repository navigation
Codex send button grayed out of after 0% usage #5694
Description
Activity
using ocx system settings --desktop-authless on
ocx sync worked but is a workaround, tho i dont think its main purpose is thisReacted by Harry Li and Aayush RI think its codex regression Ill make 98% lock as default option in next update
Related investigations: composer gating vs provider capacity
This report is directly relevant to #5733 and luvs01#619, although the same symptom does not yet prove the same underlying gate or affected app build.
The combination reported here — a custom-routed model, 0% remaining on the desktop account, and a disabled send button — together with the reporter's successful desktop-authless workaround, is consistent with a Desktop-side account/auth gate affecting input before the intended provider request is dispatched. The issue does not yet include the exact Desktop build or effective provider destination, so this is not evidence that the custom provider itself has exhausted its quota, nor proof that its credentials/capacity are valid. A custom model name alone does not establish an independent upstream.
The remedies address different parts of the problem
- Existing desktop-authless mode: the reporter has already confirmed this workaround for their installation. The integration guide explains that it changes the provider/authentication integration and can disable ChatGPT-gated account/usage/Fast-mode surfaces. It is not a quota reset, and remote-control continuity should be checked separately rather than assumed.
- Native queue fallback, fix: harden native codex queue fallback for the desktop composer luvs01/opencodex#619 (
b8cfba1): an on-demand alternate input path for an existing, otherwise usable thread, without changing TLS, app files, authentication or routing. It does not ungray the composer, switch a Reserve thread to another model, or authorize an exhausted upstream. It requires the matchingCODEX_HOMEand a queue-capable CLI/daemon. Queue acceptance is not completed execution; inspect/open/resume the same thread without resending the prompt. The helpers are currently repository-checkout scripts, not a releasedocx queuecommand. Their offline platform tests are not end-to-end evidence for this reporter's installation. - Desktop interception, feat: ChatGPT desktop send-unblock intercept (opt-in) #5733 (
57d604d): aims to restore the existing composer through a local TLS relay. It is still a draft proposal, now targetingdev, not a verified fix for this issue. The comparative review records provider/endpoint scoping, preserving non-quota blocks, certificate readiness and safe disable/recovery requirements. Those distinctions matter especially when the same app has both native and independently routed conversations.
The proposed 98% lock is a separate prevention question
Assuming the 98% lock proposal above means stopping main-account dispatch before quota exhaustion, that can help prevent reaching the problematic state; it does not restore an account already at 0% or repair the composer's provider-awareness. Usage outside the guarded OpenCodex path can also exhaust that account. Prevention and recovery should therefore be verified separately, rather than closing this issue solely because a pre-exhaustion cutoff is enabled.
Useful evidence / closure criteria
Please add the exact Desktop and bundled CLI versions, whether the intended thread uses a genuinely independent provider versus ChatGPT-forward routing, and whether any corresponding request reaches OpenCodex while the button is disabled. Redact private endpoints and identifiers; no tokens, cookies,
auth.json, prompt bodies or full account snapshots are needed.A composer fix should demonstrate an actual completed turn through the intended authorized provider while the desktop account is exhausted, preserve real native-provider and non-quota restrictions, and leave ordinary-quota behavior intact. A persistent interception solution additionally needs a tested on→off return to native networking without silently restarting active work. A successful queue submission alone is a workaround result, not that closure criterion.
- added 7 commits that reference this issue
on Sep 24, 2026 Fixed on
devby #5743 (with the follow-up in #5748): the main-account hard lock is now on by default at 98%, so requests stop using the ChatGPT main account before its window reaches 0% and Codex Desktop keeps the send button enabled while routing elsewhere. It ships in the next release (2.65.0).If you rely on Luna Reserve for the main account, turn the lock off, since Reserve only activates once the normal window is exhausted. The
--desktop-authlessworkaround is no longer needed for this case. If the button still greys out on 2.65.0, please reopen with your Codex Desktop build andocx statusoutput.Proxy: running (PID 39923)
Health: http://127.0.0.1:10100/healthz ok (live)
Dashboard: http://localhost:10100/
Config: /Users//.opencodex/config.json
PID file: /Users//.opencodex/ocx.pid
Runtime: /usr/local/lib/node_modules/@bitkyc08/opencodex/node_modules/bun/bin/bun.exe
Runtime source: bundled
Default provider: openrouter
Remote hub: disconnected
Codex autostart: enabled
Restart safety: AT RISK after restart (no viable background service; run 'ocx service install')
routing=opencodex-local, service=absent, shim=absent
Service: not installed (logs: /Users//.opencodex/service.log)
Codex autostart shim is not installed.
Codex runtime: /Applications/ChatGPT.app/Contents/Resources/codex
Codex version: 0.155.0-alpha.16.4
Codex source: configured
Codex home: /Users/[USER]/.codex
Catalog clamp: inactive
OAuth logins:
command-code ✗ not logged in
orcarouter-oauth ✗ not logged in
xai ✗ not logged in
anthropic ✗ not logged in
kimi ✗ not logged in
meta-muse ✗ not logged in
nous ✗ not logged in
kiro ✗ not logged in
google-antigravity ✗ not logged in
cursor ✗ not logged in
devin ✗ not logged in
github-copilot ✓ logged in
OAuth health: okstill greyed out... I have 100% usuage used that might be the issue?
- added a commit that references this issue
on Sep 26, 2026
Client or integration
Codex App
Area
Proxy and routing
Summary
The send button is grayed out as it thinks i have 0% usage left but im routing to a custom model, so any sort of bypass would work.
Reproduction
Latest version of codex required, not sure how i can rollback
Just any model with 0% usage
Version
2.55.0
Operating system
macos 26.2 tahoe
Provider and model
No response
Logs or error output
Screenshots and supporting files
No response
Redacted configuration
Checks