Repository navigation
[Windows Desktop 26.915.4065.0] Send button stays disabled in existing conversations; still reproduces on 26.915 (workaround: switch to Settings page and back) #46986
Description
What version of the Codex App are you using (From "About Codex" dialog)?
26.915.4065.0
What subscription do you have?
Plus
What platform is your computer?
Windows x64
What issue are you seeing?
Same composer-state bug as #45885, #45626, #45307, #45305 (Windows) and #46440 (macOS), still reproducing on the newer Windows Desktop build 26.915.4065.0:
- Open an existing (historical) conversation whose previous turn has completed.
- Type a follow-up message — text appears in the composer, but the Send button stays grayed out / disabled and the message cannot be submitted.
- Restarting the app and rebooting the PC do not help.
CODEX_CLI_PATH is NOT set on this machine, so the stale-CLI-path cause from other reports is ruled out.
New workaround discovered (not mentioned in the related reports)
Switching to the Settings page and then back to the conversation tab restores the Send button — typed messages can then be submitted normally.
This is consistent with the current working hypothesis (stuck renderer-side composer state, e.g. markedStreaming=true not being reset after latestTurnStatus=completed): navigating away unmounts the conversation view, and returning remounts it, which re-reads the conversation state from the backend and clears the stuck flag. Switching between conversations (#45885) works on the same principle.
This is only a workaround — the state can get stuck again after later turns complete, but the Settings-page round trip unblocks it each time.
What steps can reproduce the bug?
- Launch Codex Desktop 26.915.4065.0 on Windows.
- Open an existing conversation whose previous turn has completed.
- Type any message.
- Send button remains disabled; the message cannot be sent.
- Navigate to Settings, then back to the conversation → Send button becomes enabled and the message can be sent.
What is the expected behavior?
After the previous turn completes, the composer should return to an idle state and allow submitting a follow-up message without any manual view-switching.
Additional information
Related reports with same or closely matching symptoms on earlier builds: #45885, #45626, #45307, #45305 (Windows), #46440 (macOS). Still reproducing on 26.915.4065.0 suggests the fix has not landed yet.
Activity
github-actions commentedon Sep 21, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
julianna-langston commentedon Sep 22, 2026
I’m seeing the same issue on Windows desktop across existing chats.
Expected: Existing completed chats should accept typed follow-up messages, and the Send control should have an accessible name/tooltip plus an actionable disabled-state explanation.
Actual: Text can be entered, but Send remains dimmed with no explanation, blocking all follow-up messages in existing desktop chats.
luxulzry commentedon Sep 22, 2026
I can reproduce the same issue on Windows x64 with ChatGPT/Codex Desktop package
26.915.4065.0and desktop client version26.915.31945.Symptoms:
latestTurnStatus=completedtogether withmarkedStreaming=true, even though the previous turn has already completed.I also frequently see multiple
ChatGPT.exeprocesses remaining after closing the application. Occasionally, the app cannot be reopened until the remaining process tree is terminated through Task Manager. Shutdown logs contain IPC reset andEPIPEwarnings.This strongly suggests a renderer/composer lifecycle synchronization issue. The conversation view appears to retain a stale “streaming” state after resume, while navigating to Settings or the usage page forces the view to remount and reload the correct completed state.
Resetting
config.toml, clearing proxy variables, restarting Windows, and repairing local thread metadata did not provide a durable fix. The Settings/usage-page round trip is currently the only reliable workaround for me.ledouxjake890-commits commentedon Sep 22, 2026
This is also happening to me. I can still use Codex via PowerShell using "codex resume --all" and then selecting the chat I want. The chats to transfer over to the desktop app as well. I can only use my desktop app Codex if I start a new chat; otherwise, I have to use PowerShell
The problem temporarily disappeared after regenerating Codex’s global state file, but it returned the next day after rebooting the computer.
federicorv25 commentedon Sep 22, 2026
I’m encountering a similar disabled Send-button problem on Codex Desktop for Windows, version 26.917.51856. It began for me after updating; I did not experience it previously.
Expected: Eligible requests should be able to use available Codex credits after the included quota runs out, and the Send button should not remain disabled when credits are usable.
I cannot confirm whether this is the same composer-state issue or a separate quota-to-credits transition bug. Could you investigate the disabled Send button and credit availability in build 26.917.51856?
Just9n5s commentedon Sep 23, 2026
I tested the Settings-page workaround on Windows Desktop
26.917.51856.Switching to Settings and then returning to the conversation did not re-enable the Send button on my machine.
What does temporarily restore sending is:
The issue then returns again later, especially after fully exiting Codex from the Windows system tray and relaunching it.
Standalone CLI
0.154.0continues to work normally.dorlolo commentedon Sep 23, 2026
I'm seeing the same issue on Windows desktop across existing chats.
Based on these, I suspect the problem may be related to workspace loading.
whtpdbs0204 commentedon Sep 23, 2026
Additional controlled startup-order test:
I tested whether the Settings → conversation workaround depends on Blender MCP connection state.
This suggests the important condition is successful MCP initialization during ChatGPT Desktop startup, not an active Blender connection at the time the workaround is used.
Notably:
This appears consistent with a startup-only initialization/readiness/cache effect.
I am not claiming Blender MCP is the root cause of the follow-up submission bug — the bug itself was previously reproduced with Blender MCP disabled.
A possible interpretation is that successful MCP startup changes initialization ordering, query/cache invalidation, or readiness hydration in a way that allows the Settings remount/navigation to clear the blocked composer state.
The remaining question is whether this is:
codex-home/ local-config readiness path to initialize correctly.ThatcherJi commentedon Sep 24, 2026
Adding diagnostic evidence from a Windows machine with the same disabled Send-button symptom. The captured blocker was
loading-local-config; the following identifies a reply-delivery failure on this machine, rather than assuming the stale-streaming explanation applies to every case.Environment recorded during the September 23 tests
26.917.8451.0.26.917.62051, build10789.process.versions.electronreported153.0.8010.53; app-server:0.155.0-alpha.16.3.CODEX_HOMEon a secondary drive.Captured blocked state
The local app-server remained connected and continued processing requests. Both local configuration query variants were stuck with
status=pending,fetchStatus=fetching, no data, and no error:The composer reported
submitBlockReason="loading-local-config". Targeted cancellation/refetch of these reads restored sending in the existing task without restarting the desktop process.Controlled reproduction and reply-only recovery
Using local runtime instrumentation, three temporary primary windows were created through the application's window factory, one at a time, in the existing desktop process. Observers were installed before the relevant requests. Each window was observed for approximately 14 seconds, then closed; the original task window remained open.
The missing replies included both
codex-homevariants.In the second run, all 34 replies reached the low-level delivery callback that delegates to
webContents.sendoncodex_desktop:message-for-view. The delivery queue was empty at capture. The missing replies clustered roughly 3.08–3.47 seconds after window creation; replies before and after that interval arrived.In the third run, observers of
window.messagein both the main world and the preload isolated world missed the same 13 replies. Re-delivering the already generated reply objects with their original request IDs reduced pending requests from 13 to 0, checked 500 ms later. This did not re-execute the original operations or reread configuration. Dependent requests generated afterward are excluded from the baseline count of 34.This narrows the observed boundary to main-process transport delivery → preload/renderer message dispatch. The raw native IPC receive callback was not instrumented, so the exact dropping instruction is still unconfirmed.
Local mitigation validation
A temporary in-memory guard now retains small, complete
fetch-responsemessages briefly and re-delivers a reply only if the same window is still waiting for its request ID. It never resubmits the original request. Five further controlled window-start tests each automatically recovered 13 lost replies, ended with zero pending requests, and recorded zero guard-check errors.The guard has bounded retries/storage and clears entries on navigation or window destruction. Official application files were not modified. It is a local mitigation validated on this build, not an upstream fix or proof of compatibility with future releases.
Suggested investigation
Please check startup IPC delivery/readiness and the completion behavior of the renderer's
vscode://codex/request bridge. In the inspected path, pending promises had no deadline, allowing lost replies to leave local configuration—and therefore Send—blocked indefinitely. Reply acknowledgment/re-delivery or a bounded recovery path for verified read-only requests could prevent this failure from persisting.Do not blindly retry side-effecting requests: the operation may already have succeeded while only its reply was lost.
The evidence above excludes prompts, response bodies, credentials, machine-specific paths, and task IDs. Detailed local timing records were retained.
LT7T commentedon Sep 24, 2026
For Windows users still blocked after a turn has completed, I've published an unofficial open-source workaround:
https://github.com/LT7T/codex-control-command
Our investigation indicates that the disabled composer is an application-side error. This workaround does not patch Codex or claim to fix the underlying defect; an official Codex application update will be needed to resolve that properly.
Codex Command and Control runs a loopback-only local control centre, finds the intended local task, checks that Codex reports it as idle/completed, and then sends the follow-up through the local Codex host.
It also adds a task picker, reply refresh, Start/Stop controls, an explicit "End all local Codex work" action, and privacy-safe local usage/history statistics. It has no telemetry and does not copy prompt text into its statistics.
The easiest installation path is to open a fresh Codex task and paste the installation prompt from the README. Users should review the security-sensitive scripts before running them.
If switching to Settings and back restores Send, that remains the simpler workaround. This project is primarily a temporary fallback for cases where the composer remains stuck or repeatedly regresses.
ThatcherJi commentedon Sep 24, 2026
Following up on my diagnostic report: I have now published the actual recovery implementation, including the Windows blue C tray, automatic reply guard, installation/removal scripts, and tests:
Codex Blue C Recovery — source and installation instructions
It keeps the existing Codex desktop conversation as the normal place to work:
For the originally captured failure, three runs each left 13 of 34 replies undelivered; five later automatic-guard tests each recovered all 13 with zero pending requests and zero guard-check errors. The published package also passed its offline tests, tray compilation/check-only test, and a live compatibility-only probe; the temporary diagnostic listener closed afterward. A fresh copy downloaded from GitHub compiled successfully.
Installation: download the repository ZIP, extract it to a permanent writable folder, review the scripts, and run Install.cmd. Requirements and Chinese/English instructions are in the README. The tray is compiled locally from the included source.
This is an unofficial local workaround for the observed reply-delivery failure. It does not modify installed Codex files or fix the underlying desktop transport defect, and compatibility with future official builds is not guaranteed.
ledouxjake890-commits commentedon Sep 24, 2026
For me, logging out and logging back in fixes the issue, that is, until I close the app completely and open it again. However, all I have to do is log out and log back in again and the problem goes away.