[Bug] Codex Desktop model picker reopens after Luna Reserve exhaustion, but Send remains disabled

[oocheol]

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.

Reported state	Model selection	Submission
Regular allowance exhausted, Reserve still available	Reserve-only picker, as discussed in the earlier reports	Reserve continuation is the preceding workflow
Regular allowance and Reserve both exhausted	Other models become selectable again	Send remains disabled after changing the selection — the new observation

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:

1. Use Codex Desktop with OpenCodex-connected models.
2. Exhaust the ordinary Codex allowance and enter the Luna Reserve workflow.
3. Continue until the Luna Reserve allowance is exhausted as well.
4. Open the model picker again. Other models can now be selected.
5. Select another model and attempt to send a message.
6. Observe that the Send button remains disabled and the message cannot be submitted through that button.

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:

• OpenCodex dev resolved to 7868f5df570e5f5fb4be3a4b79b7e83526894e5f during this investigation.
• Public Codex source inspected at b0659c53865dd48b0cd69c454368cea3980017cc.

The older e18ca246... review baseline in #4869 should not be substituted for the installed version or assumed to remain the current dev tip.

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

1. An existing Desktop investigation provides a plausible explanation for the picker reopening. The repository's recorded analysis of Desktop 26.901.22334 / build 7746 says active Reserve requires ordinary usage to be disallowed, the gpt-reserve additional 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.

2. Public Codex TUI code separates submission handling from model selection. In input_submission.rs, submit_user_message_with_prepared_images queues input rather than dispatching it while input_queue.rate_limit_recovery_pending is set. In rate_limits.rs, finish_rate_limit_recovery clears 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.

3. The effective provider/auth context is a separate integration variable. OpenCodex's buildProviderTableBlockForTarget writes requires_openai_auth = false only 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

• Compare the last Reserve-available state with the first both-exhausted state. Record the relevant regular/Reserve permission booleans, selected model ID, effective provider/auth mode, and the actual reason the composer is disabled. Do not assume a displayed percentage alone establishes authorization.
• Trace whether selecting a routed model updates only the picker value or also the state used by submission validation. Distinguish a deliberate native-account block from stale state, a failed selection update, or another composer prerequisite.
• Verify the exact selected independent provider through a separate, minimal, explicitly authorized request using its own credentials. A successful control would distinguish provider availability from Desktop submission gating; no such successful control is claimed here.
• Trace Desktop → app-server submission and the actual OpenCodex ingress, including WebSocket traffic if used. If submission arrives, record the incoming model before normalization and local refusal/dispatch outcome. If it never arrives, proxy-side request remapping cannot affect that state.
• Compare the affected existing thread with a fresh thread and, separately, a complete client restart. An effective authless setup can be a separate control only with explicit consent for its configuration/history implications. Do not silently change the reporter's workflow during diagnosis.
• A supported resolution should let an independently authorized route submit without restoring native quota, or clearly document the specific unsupported client/build state. Verify both quota-exhaustion transitions and recovery, not only that the picker is visible.

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

• Codex Luna Reserve / gpt-reserve mode disables OpenCodex routed models after 5-hour quota is exhausted #2813 / 模型选择在gpt用量到底的时候会被系统限制死 不能选择其他模型 #4076: Reserve-active picker lockout. This report covers the next state, when the picker reopens but Send remains disabled.
• [Feature] Explicit per-thread external-provider routing during Codex Desktop Luna Reserve #4869: explicit per-thread external execution override, conditional on receiving a request. If this new state prevents submission before proxy ingress, that proposal cannot address this state. Even if a request arrives after changing the picker, its model may now be the selected model rather than gpt-reserve; the exact-match remapping assumption must not be carried over without checking.
• Toggling --desktop-authless / --client-compaction does not rewrite ~/.codex/config.toml until a separate sync, and gives no warning about the auth-source switch #4809 / Luna Reserve catalog row is silently suppressed unless the undocumented account-picker map is populated #4811 / ocx restore / stop / uninstall refuse to restore config.toml on paginated Codex history, leaving the CLI pointed at a dead proxy port #4812: settings synchronization, Reserve catalog projection, and restoration remain separate concerns. None is asserted to be this report's root cause.

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

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[Ingwannu]

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.

[oocheol]

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:

1. 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.
2. 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-reserve match 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.

[lidge-jun]

리뷰 · 우선순위 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이 작성했습니다