Repository navigation
[Bug] Codex Desktop model picker reopens after Luna Reserve exhaustion, but Send remains disabled #4878
Description
Activity
This is a useful separate report, but it is not yet confirmed as an OpenCodex defect. A disabled Send button strongly suggests the block may happen inside Codex Desktop before any HTTP/WebSocket request reaches the proxy. If no request arrives, proxy-side routing or model remapping cannot repair it.
Before proposing code, please add: the exact installed OpenCodex and Desktop/app-server builds; OS; a screenshot or short recording showing the picker and disabled composer; whether keyboard submit behaves differently; whether a fresh thread or full Desktop restart clears it; the selected model id plus effective
model_provider/auth mode; and redacted evidence of whether any request reaches OpenCodex ingress when Send is disabled. A control should use an independently credentialed provider, not another native model sharing the exhausted ChatGPT allowance.I would keep this open for diagnosis rather than close it as upstream today. Acceptance evidence is: after ordinary and Reserve quota are both exhausted, an independently authorized routed model can submit, or we can show the affected Desktop build blocks pre-dispatch and document that client limitation. No quota spoofing, reset-credit spending, or silent provider switch is needed.
Follow-up: establish the submission boundary before proposing a fix
Thanks @Ingwannu. Following your diagnostic guidance, I agree that this should remain open for diagnosis, without treating either an OpenCodex defect or an upstream Desktop defect as established.
The reported observation remains narrowly defined: after ordinary and Reserve allowances are both exhausted, model selection becomes possible again, but the Send button remains disabled. The cause, the replacement provider's availability, and whether submission reaches the proxy are still unverified. This comment organizes the evidence needed; it does not supply new reproduction results.
1. Minimum evidence for the affected installation
Evidence What needs to be recorded Exact environment Installed OpenCodex version/commit, Desktop version/build, the app-server runtime actually used by Desktop, and OS/version/architecture. A source-review commit or an unrelated CLI found on PATH is not a substitute for those installed builds. Visible failure A redacted screenshot or short recording showing the reopened picker, selected model, a non-empty text-only draft, and disabled Send button. Exclude private workspace/content details. Record whether another composer prerequisite is blocking submission, such as an active turn, pending approval, attachment validation, or disconnected app-server. Effective route Exact selected model ID, effective model_provider, and native-auth requirement/auth mode. Record local versus remote proxy topology and whether authless is actually effective, not merely enabled in saved configuration. Do not publish credentials or account identifiers.Submission methods Button state and the result of one deliberate keyboard-submit attempt using the configured shortcut. Record separately whether it dispatches, queues the draft, or does nothing. Avoid repeated attempts that could create duplicate submissions. State lifetime Whether the same problem occurs in a fresh thread, and whether a full Desktop/app-server restart changes existing-thread and fresh-thread behavior. Capture the original failure before restarting so transient evidence is not lost. Request boundary A time-correlated, redacted summary of Desktop-to-app-server submission and actual OpenCodex ingress, including the transport, path, and incoming model before normalization when a request is observed. Keep the quota state and selected provider recorded for each comparison. If either allowance recovers during the tests, a newly enabled composer cannot be attributed to a fresh thread or restart alone.
2. Use an independent-provider control
The control should use the same independently credentialed provider/model, preferably through the same OpenCodex instance, with a minimal non-sensitive request explicitly authorized by the operator. Another native model using the exhausted ChatGPT account would not isolate this problem.
A successful control would establish that this route can execute at that time; it would not prove that Desktop has adopted the same effective route or authentication context. Record the actual resolved provider/model where available, not only the picker label. No successful control is being claimed yet.
Do not change the affected workflow to authless before capturing it. An authless comparison is a separate, explicitly agreed control, not evidence that the original native-auth workflow works.
3. Distinguish the possible failure boundaries
- Keyboard submission works while the button stays disabled: investigate disagreement between button enablement and the submission handler. Verify actual dispatch, not just disappearance of the draft.
- No submission leaves Desktop: investigate composer/selection/recovery state in the affected build. Proxy-side remapping cannot act on a request that never arrives.
- Desktop submits to app-server, but nothing reaches OpenCodex: inspect app-server validation, effective routing, and connection failures before attributing the failure specifically to the Desktop renderer.
- An inference request reaches OpenCodex: capture its incoming model and local rejection/dispatch outcome, then investigate that observed path. Request arrival alone does not establish that OpenCodex caused the disabled button.
An empty usage log, or the absence of a new WebSocket connection, is insufficient negative evidence: the observation must cover the actual ingress and messages on any existing connection. Use a known control to establish capture coverage, and distinguish inference traffic from background usage/model polling.
4. Acceptance and scope
Two useful outcomes are:
- Supported execution: with ordinary and Reserve allowances still exhausted, an independently authorized routed model can submit and complete a minimal request. Native quota enforcement remains unchanged.
- Diagnosed client limitation: evidence identifies the affected Desktop/app-server build and demonstrates a pre-proxy submission block with adequately covered observations. Document that precise limitation and supported alternatives; do not describe it as a proxy fix.
Until that evidence exists, neither closing this solely as upstream nor proposing a quota-state/remapping patch would be justified. #4869 remains a separate, request-arrival-dependent proposal; it cannot repair this state if nothing reaches the proxy, and its exact
gpt-reservematch must not be assumed after another model is selected.Current evidence status: exact installed builds, OS, screenshot/recording, replacement model/effective auth context, keyboard/fresh-thread/restart results, and ingress/control results are still outstanding in this report. No new test success or confirmed root cause is claimed here. No quota spoofing, reset-credit spending, authorization changes, or silent provider switch is requested.
리뷰 · 우선순위 44 / 80
이 이슈는 Codex Desktop + OpenCodex에서 일반 Codex 허용량과 Luna Reserve가 모두 소진된 뒤, 모델 피커는 다시 다른 모델을 고를 수 있는데 Send 버튼은 계속 비활성이라 전송이 안 된다는 관측이다. #2813·#4076·#4869 계열의 다음 상태 전이로 적혀 있다.
작성자는 #4869(스레드별 외부 프로바이더 라우팅 기능 요청)의 구현 요청이 아니라, 별도 UI/통합 호환 관측이라고 선을 긋는다. tip 41f1832(package 2.58.0). 이미 스레드에 "요청이 프록시까지 안 오면 OpenCodex 라우팅으로 고칠 수 없다"는 진단 가이드와, 작성자의 follow-up(경계부터 확정)이 있다.
OpenCodex tip 코드만으로 Send 버튼 상태는 재현되지 않는다. Luna/Reserve 관련 문자열은 검색·비전 헬퍼 거절 메시지, quota 분류, Desktop 스위치(--desktop-authless 등)에 흩어져 있고, Desktop 클라이언트 위젯 enablement는 이 저장소 밖이다.
#4899(Desktop stored≠effective 보고)는 tip에 있지만 Send disabled와는 다른 축이다. 이 이슈의 올바른 다음 스텝은 코드 PR이 아니라 제출 경계 증거다. 프록시 access log에 요청이 있는지, app-server가 막는 메시지인지, 선택된 모델 id와 인증 레인을 먼저 고정해야 한다.
경로/심볼 - Codex Desktop UI: Send enablement. 프록시 미도달이면 OCX 패치 대상 아님
경로/심볼 - #4869: 인접 기능 요청. 이 이슈는 구현 요청이 아니라 관측 분리
경로/심볼 - #4899 settings effective: Desktop 스위치 보고. Send disabled와 동일 결함으로 묶지 말 것
경로/심볼 - 이슈 본문 재현 5–6단계: Reserve 소진 후 피커 복귀 vs Send 잔여 disable이 구분점메인테이너의 판단이 필요한 지점
- OpenCodex 결함 vs Desktop 클라이언트 결함 vs app-server 상태 — 아직 미확정
- 라벨 bug/catalog는 유지하되 책임 단정은 보류할지
- 증거 최소 세트(OCX/Desktop 빌드, OS, 선택 모델 id, 프록시 로그 유무)를 이슈에 고정할지
너의 추천
코드 변경 PR을 열지 말고, 이슈에 증거 체크리스트만 고정한다. 프록시 로그에 요청이 없으면 upstream Desktop 쪽으로 이관/링크한다. 요청이 오면 그때 tip 기준으로 routing/quota 거절 응답을 추적한다.이 댓글은 grok-bot이 작성했습니다
Triage:
priority: P1— Send stays disabled after Luna Reserve exhaustion; user blocked.Criteria (P1): High: reproducible failure in a core path (routing, failover, account pool, streaming, usage, auth, install) with no clean workaround; or a small (<300 LOC) bug-fix PR for such a failure.
Matched pull requests:
- feat: ChatGPT desktop send-unblock intercept (opt-in) #5733 (related / partial) — feat: ChatGPT desktop send-unblock intercept (opt-in) [
priority: P3]
- feat: ChatGPT desktop send-unblock intercept (opt-in) #5733 (related / partial) — feat: ChatGPT desktop send-unblock intercept (opt-in) [
Related to #5694, but retain the post-Reserve-exhaustion case
Yes: this belongs to the same desktop submission-gating symptom family as #5694 and the proposal in #5733. The existing bot match already identifies #5733 as related/partial. The additional cross-reference is useful because #4878 records a more specific transition: ordinary and Luna Reserve allowances are both exhausted, the picker reopens, but Send remains disabled. #5694 does not establish that Reserve transition, so a shared root cause or an exact duplicate is not yet demonstrated.
New evidence from #5694
The maintainer closed #5694 after #5743 and #5748, describing the default-on 98% main-account hard lock. However, the reporter subsequently reported that Send was still greyed out with 100% usage. That follow-up includes Codex runtime version
0.155.0-alpha.16.4, but does not establish the updated OpenCodex version, effective hard-lock state, exact Desktop build, or Reserve status. It is a useful related observation, not proof of a regression in a particular release or a reproduction of every condition in #4878.Prevention and recovery should remain separate:
- fix(codex): bundle L4 — service uninstall key, startup rollout budget, sub-agent identity, agent-message recovery, 98% main lock #5743 makes the main-account admission guard default-on at 98%. It can help avoid exhaustion on guarded requests, but does not replenish already exhausted allowances or establish that an already-disabled composer recovers. Its merged policy code evaluates observed quota; it is not a reservation of remaining capacity. The PR also notes that blocking before exhaustion prevents entry into the main account's Reserve workflow while the lock is effective.
- fix(codex): keep native-main admission open across startup convergence and stop #5748 fixes startup-convergence/stop admission fencing after the default change. That is not, by itself, evidence that the Desktop's post-Reserve Send state is repaired.
Related approaches, not verified closure evidence
#5733 remains a draft at
57d604d. The comparative design review covers provider/endpoint scoping, preservation of non-quota blocks, certificate readiness and safe disable/recovery. Its proposed composer repair still needs verification against this exact both-exhausted transition, not only ordinary-quota exhaustion.The on-demand native-queue helper in luvs01#619 (
b8cfba1) is an alternative input path for an otherwise usable, independently authorized thread; it does not repair the picker/composer, switch the thread's provider, or restore native quota. Matching CLI/daemon support is required, and queue acceptance alone is not a completed model turn. No successful end-to-end result for #4878 is claimed.The existing diagnostic checklist already covers the right boundaries, so there is no need to repeat it. Please retain regular-available, regular-exhausted/Reserve-available, both-exhausted, and recovery as distinct test states, checking the effective selected provider plus Desktop → app-server → OpenCodex dispatch and actual completion. Keep native-provider and non-quota restrictions intact. Linking #5694/#5733 is appropriate; closing #4878 solely because the 98% prevention guard landed would lose the unresolved recovery case. This comment adds cross-issue evidence, not a new reproduction or a request to change authentication, spend reset credits, or deliberately exhaust an account.
Tracking note: grouped the related exhaustion reports under this issue as sub-issues.
- Codex GUI blocks prompt submission at 100% usage, including with other models #5797 — same symptom family on Windows (ocx 2.64.0, app 26.917.71314): submit disabled at 100% usage for all models, restored after reset or another account. Reserve state not specified.
- Codex send button grayed out of after 0% usage #5694 — closed earlier report of the same family (send grayed out at 0% usage, macOS, v2.55.0). Kept closed; linked for history since its author later re-reported the disabled state at 100%.
Deliberately kept separate rather than merged: this issue covers the deeper state where both the regular allowance and Luna Reserve are exhausted and the picker reopens while Send stays disabled, whereas #5797 only documents regular-allowance exhaustion. If verification shows the same underlying gate, maintainer can mark one as duplicate of the other.
Related but not sub-issues (different layer or ask): #4961 (Reserve capability bound to codexDesktopAuthless flag), #4869 (per-thread external-provider routing during Reserve), #5649 (configurable low-quota threshold actions), #5616 (auto-resume a turn after mid-stream limit cut).
Thanks — this is the correct evidence boundary. There is still no new reproduction result that locates the failure before or after OpenCodex ingress, so a proxy patch would be speculative.
I am marking this
needs-infoand leaving it open. The next actionable evidence is one affected run with the exact installed Desktop/app-server/OpenCodex builds, selected replacement model and effective auth route, keyboard-submit result, and a time-correlated ingress capture plus an independently credentialed control. Once that shows where submission stops, the issue can move back to implementation without guessing or changing quota enforcement.Reacted by ratu.sh98%-safeguard not works. Codex bypass it and derive usage to 100%.
Additional Windows evidence from the current installed app; this does not claim the full post-Reserve transition is reproduced or fixed.
- Installed Codex Desktop:
26.924.1866.0; app-owned CLI observed in this investigation:0.158.0-alpha.2; serving OpenCodex:2.67.0. - Native ChatGPT sign-in remains enabled, the effective Codex provider is
openaiwith inference directed to the loopback OpenCodex endpoint, and authless/client-provider rewriting is off. No application patch, TLS interception, usage rewrite, reset-credit consumption, or production package replacement was used for these checks. - The current account status reports ordinary usage unavailable and weekly use at 100%, with no spend-control block. Reserve state is not independently established by that response.
- In this installed Desktop bundle, the local composer uses account-level usage predicates that do not take the selected model/provider as input. The usage source includes the app's own
/wham/usageHTTP/SSE path, so changing only app-serveraccount/rateLimits/reador inference routing does not establish that this composer state changes. - Independently routed Gemini and Devin requests both completed through the running proxy. A separate synthetic compaction experiment preserved a marker and latest goal across Gemini summary → Devin continuation. This is an inference-path control, not proof of keyboard submission through the blocked original composer.
The user has now reconfirmed that the original local Send button itself is disabled. This is distinct from the separately observed Devin upstream errors after requests sent through another path. A timestamped Enter attempt and current selected-model identity were not captured, so I am not claiming a complete ingress-localized keyboard reproduction or that Reserve is exhausted. The next missing evidence remains that narrow UI/ingress correlation; the source-level provider-blind gate and successful independent inference control make a proxy-only model-dispatch fix insufficient on the evidence available.
Scope clarification: current #5733 is an opt-in macOS ChatGPT desktop TLS-interception integration. It is related research, not an already verified repair for this Windows Codex Desktop gate. #5919 is failure-only routed compaction recovery and does not change the composer or recover 429 failures.
- Installed Codex Desktop:
- added a commit that references this issue
on Sep 26, 2026 Release train 4 (account-pool lane) reviewed this against
dev24b2f39b77together with #5879. Keeping it open; no proxy change ships for it in this train.Why #5879 is not treated as the fix. It turns
codexDesktopAuthlesson while the main account's quota reads as exhausted and off again on recovery. That can lift Desktop's account gate for the ordinary-exhausted case, but three things stop it from closing this issue:- Nobody has run it against the state reported here: ordinary allowance and Luna Reserve both exhausted, picker reopened, Send still disabled.
- Its worker counts a transition as applied once the setting is saved, even when rewriting the Codex config fails. Desktop can then restart on the old provider form while OpenCodex believes the switch happened.
- Reserve eligibility is currently tied to the same flag (Luna Reserve capability is bound to codexDesktopAuthless, a flag documented as controlling Codex app sign-in #4961), so flipping it automatically also changes who gets Reserve.
On the "98% safeguard does not work" comment. The main-account hard lock refuses new OpenCodex admissions to the main account once a fresh 5-hour or weekly reading is at or above 98%. It cannot stop usage that never passes through OpenCodex, such as Desktop's own ChatGPT-signed-in traffic or another client on the same account. A request admitted at 97% can also finish above 98%. Usage reaching 100% therefore does not by itself show a bypass. A request log line showing OpenCodex admitting a main-account request after a ≥98% reading would, and we would treat that as a bug.
Evidence that would move this forward, from one affected run on the installed Desktop/app-server/OpenCodex builds:
State Needed Ordinary available Baseline: Send works; request appears in ocx logsOrdinary exhausted, Reserve available Selected model, Send and Enter result, matching ingress line or its absence Both exhausted The same, plus whether the picker reopened After reset or a switch to another account The same If a request reaches OpenCodex and fails, we can diagnose it here. If no request is sent, the gate is in the Desktop composer and a proxy-side routing change cannot fix it.
Closing as a duplicate of #6196. The same Desktop Send gate is now handled by the opt-in macOS app-server shim in #6361 (squash
fcbfb16c00). The shim clears the plain-quota gate and deliberately leaves any non-quota reached type closed. If Send still stays disabled after Luna Reserve exhaustion with the shim active (chatgptDesktop.appServerShim: true,ocx chatgpt launch), please reopen and include therateLimitReachedTypeandordinaryUsageAllowedvalues from that state, so we can tell whether it is a different gate.Automated translation bookkeeping — detected language: English.
- added a commit that references this issue
on Oct 1, 2026
Client or integration
Codex App
Area
Catalog / models
Summary
I observed a further state transition in the Codex Desktop + OpenCodex workflow discussed in #2813, #4076, and #4869:
After both the regular Codex allowance and the Luna Reserve allowance are exhausted, I can select another model again, but the Send button remains disabled, so I cannot submit a message.
The distinction is important: the picker is no longer the visible blocker. Model selection becomes possible again without restoring the ability to send.
This is a separate observed UI/integration compatibility problem, not an implementation request for #4869. It does not yet establish whether the defect is in Desktop, app-server state, or how the OpenCodex integration is represented to the client.
Expected behavior: exhausted native models should remain subject to their real limits. When the selected model is an independently authenticated OpenCodex route with valid credentials and remaining provider capacity, its submission availability should not be inferred solely from exhausted native ChatGPT/Reserve allowances. If Desktop cannot support that distinction, it should communicate the client-wide limitation and an actionable supported alternative rather than make selection appear to restore usability.
The exact replacement model ID and its independent availability still need a controlled check. This report does not claim that every selectable model is entitled or that an exhausted native account should be allowed to send.
Reproduction
Reported sequence, not an independently reproduced laboratory test:
The distinguishing boundary is step 3: Reserve available → Reserve exhausted while ordinary usage is still exhausted. Testing only ordinary-quota exhaustion misses this second failure state.
Before attributing the disabled state to quota handling, a controlled reproduction should also confirm a non-empty text-only prompt, no pending attachment validation, no active/stuck turn or approval dialog, and a connected app-server. Keyboard-submit behavior, fresh-thread behavior, restart behavior, and provider reachability have not yet been verified for this observation.
Version
The installed OpenCodex version and exact Codex Desktop/app-server build have not yet been captured for this observation.
Source-analysis references, not claims about the installed binaries:
devresolved to7868f5df570e5f5fb4be3a4b79b7e83526894e5fduring this investigation.b0659c53865dd48b0cd69c454368cea3980017cc.The older
e18ca246...review baseline in #4869 should not be substituted for the installed version or assumed to remain the currentdevtip.Operating system
Not yet recorded for this specific observation. No OS/build is inferred from other reports or source-analysis environments.
Provider and model
The transition involves the native
gpt-reserve/ Luna Reserve state. The exact model selected after the picker reopens has not yet been recorded.Please distinguish an independently credentialed provider/model from another native model using the same exhausted ChatGPT allowance. Both the selected model slug and the effective Codex
model_provider/auth mode matter; a model-label change alone does not prove that the client changed its account context.Logs or error output
No redacted ingress capture, HTTP status, or exact client error text is attached yet. The observed failure is a disabled Send button, not a demonstrated HTTP 429 after submission.
Request arrival at OpenCodex remains unverified. A disabled button suggests a pre-dispatch block, but absence from a particular request log is not proof unless that log covers the actual HTTP/WebSocket ingress. Keyboard submission and Desktop-to-app-server submission need to be checked separately.
Screenshots and supporting files
No screenshot or recording is attached. The following source references inform the investigation; they are not substitutes for a capture from the affected Desktop build.
Source findings and their limits
An existing Desktop investigation provides a plausible explanation for the picker reopening. The repository's recorded analysis of Desktop
26.901.22334/ build7746says active Reserve requires ordinary usage to be disallowed, thegpt-reserveadditional allowance to be allowed, and the relevant banner/eligibility conditions. It also records a Reserve-only picker while that state is active. Inference: if the additional Reserve allowance stops being allowed, that particular picker restriction can cease to apply even though ordinary usage has not recovered. The cited record does not establish the Send-button predicate, and it is not an inspection of my currently installed Desktop bundle.Public Codex TUI code separates submission handling from model selection. In
input_submission.rs,submit_user_message_with_prepared_imagesqueues input rather than dispatching it whileinput_queue.rate_limit_recovery_pendingis set. Inrate_limits.rs,finish_rate_limit_recoveryclears that hold separately and returns early while waiting for Reserve. These are TUI reference paths, not proof that Desktop uses the same fields or has the same defect. They support investigating submission/recovery state independently instead of assuming picker availability means submission readiness.The effective provider/auth context is a separate integration variable. OpenCodex's
buildProviderTableBlockForTargetwritesrequires_openai_auth = falseonly for the effective Desktop-authless target. A comparison with an effective independent-provider configuration may help localize the issue, but authless is a separate workflow, not a proven fix for this report.Working hypothesis, not a confirmed root cause: the Reserve-specific picker restriction is released when Reserve is no longer available, while a separate native-quota submission guard or stale recovery state still blocks the composer. Switching the displayed model may not update the scope or invalidation of that submission guard.
Focused investigation / acceptance criteria
Publish only a minimal redacted summary. Do not attach raw prompts, request bodies, credentials, cookies, account/session/thread identifiers, or unrestricted usage responses. This investigation does not call for spending reset credits, patching quota responses, disabling authorization, or silently sending conversation data to another provider.
Relationship to the existing issues
gpt-reserve; the exact-match remapping assumption must not be carried over without checking.Please track the post-Reserve-exhaustion submission state separately during triage, even if it ultimately belongs upstream. A client-side diagnosis would be a useful outcome; it should not be reported as a proxy fix without evidence.
Redacted configuration
No configuration dump is attached yet. The effective
model_provider,requires_openai_auth, proxy topology, selected routed model ID, and whether Desktop-authless is actually applied need to be captured without secrets.Verification status: this is a reporter-observed symptom with AI-assisted source analysis. The state transition above is the observation; the proposed cause, request arrival, provider control test, and any workaround remain unverified. No implementation PR or successful end-to-end fix is claimed.
Checks