Windows Codex Desktop: Send button becomes disabled after the first successful turn

What version of the Codex App are you using (From “About Codex” dialog)?

26.908.40834

What subscription do you have?

GPT Pro

What platform is your computer?

Windows 11 x64

What issue are you seeing?

On Windows Codex Desktop, a newly created conversation works normally for exactly one turn. After the assistant completes the first response, I can type a follow-up message, but the Send button remains greyed out/disabled and the second message cannot be submitted.

What steps can reproduce the bug?

Launch Codex Desktop on Windows.
Create a new conversation.
Send ping1.
Wait until Codex successfully responds.
Type ping2.
The Send button is disabled, so the follow-up cannot be submitted.

What is the expected behavior?

After the first turn completes, the composer should return to an idle/ready state and allow another prompt to be submitted.

Additional information

Actual behavior:
The first turn completes successfully, but the composer/send state does not recover. The Send button remains disabled for subsequent turns.

Important isolation result:
Codex CLI on the same Windows machine, using the same account, model, project and network connection, successfully completes 3+ consecutive turns. This suggests the issue is specific to Codex Desktop's conversation/composer state rather than the model or Codex backend.

Troubleshooting already performed:

Fully terminated all ChatGPT.exe and codex.exe processes and cold-started Desktop — still reproduces.
Changed Follow-up behavior from Queue to Steer — still reproduces.
Created new conversations — still reproduces.
Codex CLI multi-turn conversation works normally.

Environment:

Windows
Codex Desktop: 26.908.4834.0
Model: GPT-5.6 Sol, Medium reasoning
Network uses Clash Verge/Mihomo with TUN enabled. However, Codex CLI works normally over the same network path.

Potential area to investigate:
The Desktop client may not be resetting the composer/turn state after receiving the completion event for the first turn. It would be useful to check whether the renderer still believes a turn is active (isSubmitting / isRunning / active writer state) even after the backend turn has completed.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Windows: composer Send button stays disabled; voice and message editing still create turns #45305
Windows Desktop 26.903.61454: follow-up messages cannot be sent after the first completed turn #44102
[Windows Desktop] Second message stalls after first turn completes #44295
Codex Desktop App freezes on the second message #44590

Powered by Codex Action

Follow-up diagnostic evidence: submission stalls before app-server

Further controlled testing on this machine refines the original report: Windows Codex Desktop follow-up submission hangs inside the Desktop composer/submission path before the second turn reaches app-server.

The pale Send button is not simply permanently disabled after the first response: accessibility reported it enabled before the click; the click was accepted, then Send became a persistent spinner with the draft retained.

Reproduction and expected/actual behavior

Open Codex Desktop on Windows and create a fresh local task.
Send ping-test-1 (requesting only pong-test-1).
Wait for successful completion.
Enter ping-test-2 and click Send.

Expected: dispatch the second prompt and run another turn.

Actual: persistent spinner and retained draft; no second turn/start, queued submission, or task_started was recorded. Backend reads still reported the task idle, first turn completed, and error null.

Controlled timeline

All timestamps below are on 2026-09-14 in UTC. This is a summary of Desktop logs, session JSONL events, state reads, and timestamped UI observations, not a verbatim log dump. Task identifiers are truncated.

UI-only reproduction, task 01a09d52-654d…:

UTC time	Observation
00:30:26.741	First `task_started`; `turn/start` RPC succeeded at 00:30:26.742.
00:30:29.913	First `task_complete`, returning `pong-test-1`.
00:30:51.408	Entered `ping-test-2`.
00:30:56.325	Accessibility showed Send without a disabled marker.
00:31:02.986	Clicked Send; spinner appeared and draft remained.
00:31:30	Successful state reads: task idle, first turn completed, error null.
00:32:19.876	Still spinning almost 77 seconds after the click; no second turn or queued submission recorded.

Strong isolation: another turn succeeds in the SAME task

A separate fresh task, 01a09d4a-b01e…, was initially created through the app API; its follow-up was attempted through the Desktop composer:

UTC time	Observation
00:21:58.932	First turn completed normally.
00:23:29.119	Clicking the UI follow-up Send produced the same persistent spinner.
00:25:17.664	While that draft remained stuck, `send_message_to_thread` successfully started a second turn in the same task.
00:25:19.672	API-triggered turn completed with `pong-test-2-api-control`.
00:25:38.012	Desktop displayed both successful answers while the original `ping-test-2` UI draft continued spinning.

The task remained valid, and app-server/model execution could complete a second turn while the composer submission remained stuck. The API bypass did not clear the stuck UI draft.

CLI control and unsuccessful workarounds

Codex CLI on this Windows machine completed at least three consecutive turns using runtime 0.154.0-alpha.6.2. The interactive CLI JSONL records three completions on 2026-09-13 UTC, at 05:19:56.535, 05:20:01.139, and 05:20:05.282.

Switching follow-up behavior from Queue to Steer and fully terminating ChatGPT.exe/codex.exe before a cold start did not resolve the Desktop issue.

Misleading log signal and network correction

Received turn/completed for unknown conversation was investigated: those IDs belonged to auxiliary jobs explicitly tagged thread_title, not either visible task. This is not evidence that the visible first-turn completion was discarded.
Correction to the original network description: V2RayN/Xray/sing-box were active during the controlled reproductions; Mihomo/Clash was not active.
Genuine earlier errors included ERR_NETWORK_CHANGED, connection reset 10054, and hostname resolution 11001. However, inspection of Desktop logs and retained app-server warning/error records across approximately 00:21:45–00:32:19 UTC found no relevant network-change, DNS, reset, stream-disconnection, or reconnect error preceding either failed follow-up. Background network instability existed elsewhere in the session, but networking was not established as the cause or trigger. Log absence does not rule out every unlogged event.

Likely investigation area, not a proven root cause

Read-only inspection of the installed Desktop code shows a composer submission lifecycle separate from model-turn running state:

Evr.submitComposer → guards → set submission lock → await cvr(...) → finally clear submission lock

cvr includes preparation, local-context construction, and eventual submission. Existing idle local tasks also pass through await getTurnCoordinator() and deferAutomaticTurns(conversationId). An unresolved submission operation could keep the lock/spinner active despite an idle backend. The exact unresolved promise was not established; neither coordinator call nor any particular await is proven responsible. Renderer preparation/configuration/IPC boundaries are investigation candidates.

Environment

Windows x64
Desktop package: 26.908.4834.0
Logged client release: 26.908.40834
Bundled runtime: 0.154.0-alpha.6.2

Related reports reviewed: active #44102 and #45305; recently closed #44295, #44590, and #42952. Adding these results here rather than opening another issue. No raw transcripts, private paths, credentials, or proxy/server details are attached.

Also encountering this on Windows with installed package version 26.908.4834.0.

The first typed message in a new conversation sends successfully.
Attempting a second typed message leaves the send icon spinning indefinitely.
The same pattern occurs in new conversations.
Fully quitting and restarting the desktop app did not resolve it.
Voice messages and messages from the phone app still work.
The problem began before trying voice mode, and ending voice mode does not clear the spinner.

Expected: after a response finishes, another typed message can be submitted normally.

Local desktop logs contain repeated Received turn/completed for unknown conversation errors. The connection between those log entries and the stuck composer is unconfirmed.

No raw logs or conversation contents are attached.

I can reproduce this on Windows with Codex Desktop package 26.908.4834.0.

Observed behavior:

Regular ChatGPT chats continue to work normally.
In Work/Codex, the first prompt succeeds and the assistant responds.
After that, I can type a second prompt, but the Send arrow remains disabled/greyed; pressing Enter leaves that Work chat stuck so I can no longer continue in that thread.
Switching to another regular chat still works, so this is isolated to Work/Codex rather than the whole app.

Relevant diagnostics from the desktop log include:

Received turn/started for unknown conversation
Received turn/completed for unknown conversation
thread_stream_view_activity_changed ... resumeState=resumed

Before reaching this state, the same installation also hit failed to load configuration: invalid transport in mcp_servers.codex_app. Renaming the cached codex-app-tools plugin folders allowed the first Work turn to start successfully, but the second-turn composer/send-state bug remained.

Important workaround/isolation result:

Installing and using the separate ChatGPT Beta app on the same Windows machine/account fixes the issue completely: old Work chats and multiple consecutive Work turns work normally there.
The stable app still reproduces the stuck second-turn behavior.

This looks consistent with a Stable Windows Desktop conversation/composer state issue rather than an account/backend problem.

I’m seeing the same issue on Windows Codex Desktop. The composer accepts text normally, but the Send arrow remains greyed out/disabled, so the prompt cannot be submitted. This has happened repeatedly rather than as a one-off. The UI otherwise remains responsive. I can provide a screenshot and additional environment details if useful.

Adding another reproduction case from Windows Desktop.

Environment:

Windows Desktop ChatGPT/Codex app
Version: 26.904.11930
Web version works normally on the same account

Symptom:

Create a new conversation.
Send the first message.
First response completes successfully.
Type and send a second message.
The second message cannot be submitted / remains stuck.

Troubleshooting performed:

Verified Codex runtime components:
- codex.exe present
- codex-code-mode-host.exe present
- codex-windows-sandbox-setup.exe present
Found and removed a stale incomplete runtime (d0097be4feba73d0) that was missing host/sandbox components. This fixed Codex local runtime/file operation issues, but did NOT fix the follow-up message problem.
Confirmed active runtime works:
C:\Users\<username>\AppData\Local\OpenAI\Codex\bin\12219cbfbcbddde7\codex.exe
Reset the Windows app.
Fully reinstalled the Desktop application.
Tested after reinstall with clean state.

Result:

First turn: works.
Second and later turns: fail.
Browser version: works.

This appears to be a Desktop composer/session state issue rather than a Codex runtime installation problem. The failure happens before a new turn is successfully submitted.

Additional isolation:

Local Codex runtime components are healthy.
Authentication succeeds.
Existing/new conversations show the same behavior.

Please consider this another affected Windows Desktop reproduction.

I finally found a fix for this issue.

In my case, Codex Desktop could send the first message normally, but the second message would get stuck and never send.

The cause turned out to be an authentication problem. My Google account password had been changed, but Codex still showed me as logged in, so I didn’t realize the login session had become invalid.

What fixed it for me was:

Change/reset the password of the Google account linked to ChatGPT.
Sign out of Codex completely.
Sign back in to Codex with the same Google/ChatGPT account.

After logging in again, multi-turn conversations started working normally and the second-message issue disappeared.

So if Codex can send the first message but gets stuck on the second one, I recommend trying a full re-login, especially if your Google account password has changed recently.

Thanks — this fixed it for me as well.

I had exactly the same Windows Codex Desktop symptom: the first message worked normally, but the second/follow-up message could not be sent.

I had already tried resetting/reinstalling the Desktop app and verified that the local Codex runtime components were healthy, but the issue remained. After fully signing out of Codex/ChatGPT Desktop and signing back in to the same ChatGPT account, multi-turn conversations started working normally again.

So in my case this also appears to have been an authentication/session-state issue rather than a Codex runtime problem. Thanks for sharing the workaround!

Another affected Windows installation, with recurrence across Desktop updates.

Environment: Windows 11 Pro x64, build 26200. Installed MSIX package versions observed: 26.908.9136.0 (Sep 15), 26.911.7940.0 (Sep 17), and 26.915.3509.0 (Sep 18).

Symptoms: multiple conversations stop accepting follow-up messages after a successful first response. The Send button appears dimmed; Enter can produce a spinner without submitting. The same conversation history remains usable via Codex CLI.

Diagnostic observations:

On Sep 17, the affected first turn was completed in the local turn history, and Desktop received its completion notification. No subsequent turn/start was observed before repair.
A targeted reset of temporary client/thread associations was attempted, then reverted after a restart produced a completely black main window. Reverting the change and restarting did not recover the window. The association hypothesis is NOT established.
Resetting only the active profile's Chromium code/graphics caches did not resolve that black window.
With Desktop closed, backing up and moving aside Default/Local Storage and Default/Session Storage in the active profile, followed by a normal Windows app launch, restored the interface. The user confirmed both the display and message sending worked. The primary renderer then completed account lookup, mounted its routes, and logged a successful turn/start.
The active profile on this installation is under %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex (the nested web\Codex matters). Conversation histories and SQLite databases were not reset.
On Sep 18 the problem was reported again, now with package 26.915.3509.0 installed. In the pre-repair launch, primary account lookup and route mounting succeeded, and thread read/resume requests returned successfully, but no turn/start appeared in that launch's logs. Therefore the black-window startup failure and the send blockage should not automatically be treated as the same defect.

The UI-storage reset has been repeated today; startup succeeds, while the post-repair two-message user test is still pending. The update/state-migration connection is suspected because the issue recurred after a version change, but causality and the exact problematic storage key have not been established. This is a temporary recovery observation, not a durable fix or a recommendation to wipe the entire app profile.

Please investigate the Windows renderer submission lifecycle and persisted-state restoration/migration across app updates. No raw logs, conversation contents, account identifiers, or private project paths are attached.

Reproduced on Windows with Codex Desktop package version 26.915.4065.0 (local app-server 0.155.0-alpha.9.2). The installed package version matches the production Windows update manifest checked on September 19, 2026.

Current reproduction:

Create a new text conversation and send a short greeting.
Wait for the assistant's response to finish.
Type a second message: the Send arrow remains disabled, and Enter does not submit it.

Diagnostics verified during this occurrence:

The first turn is completed, with no execution error; the conversation is idle.
Ordinary account usage is allowed and usage limits are not exhausted.
Voice conversation remains usable during the current occurrence.
Ending Voice and switching away from/back to the conversation did not restore typed submission, according to the user's checks.
Application logs repeatedly contain ResizeObserver loop completed with undelivered notifications. This is an observation only; no causal link to the disabled composer has been established.

Earlier voice WebSocket handshake failures were also observed, but there is no evidence linking them to the composer issue. No credentials, raw conversation transcripts, account identifiers, or raw log files are included here.

Could the team advise on supported renderer/composer diagnostics or a narrowly scoped recovery that preserves conversation history and settings?

FIX

Hey peeps 👋 Deleting local memories got Codex working again for me.

To try it:

Open Codex Settings and find Codex memory.
Next to Delete local memories, click Delete. This deletes the memories stored locally on your computer.
Try sending a message again.

I doubt this is a permanent fix, but it’s helped me keep going. If the issue returns, you could try repeating it- just remember that it clears your local memories each time.

Let me know how you go with this workaround!

Screenshot from the Codex Desktop app attached for reference. Let me know how you go with this workaround!

I had this issue too. Reinstalling and deleting local memories didn't fix it, but logging off and on again did.

I can reproduce the same issue on the newer Codex Desktop for Windows package 26.915.4065.0.

Reproduction:

Launch Codex Desktop on Windows.
Create a new conversation.
Send a first message (for example, Test 1).
Wait for the response to complete.
Type and attempt to send a second message in the same conversation.

Actual behavior:

The first turn succeeds.
Every second and subsequent turn in that conversation gets stuck.
The Send button is disabled/grey and shows a spinner, but no new run starts.
Existing longer conversations exhibit the same behavior.
Regular ChatGPT conversations continue to work.

Troubleshooting already performed without resolving the issue:

Fully terminated and restarted the visible app through Task Manager.
Used Windows Repair for the installed app.
Restarted the Windows service CodexSandboxService.OpenAI.Codex successfully and confirmed it returned to Running.
Created multiple new conversations.

A full Windows reboot temporarily restores functionality, but the problem recurs. Restarting only the app or the sandbox service does not.

This suggests the Desktop renderer/composer state is not returning to idle after the first completed turn, and the regression remains present in package 26.915.4065.0.

I can reproduce the same issue on Windows Desktop, and I have some additional diagnostics that may help.
Environment

Windows 11 Pro
OS build: 22621
ChatGPT/Codex Desktop: 26.915.31945
Session ID: 01a014c5-8f7b-7cb0-91c0-61e102ffb416
Reproduction

Create a brand-new Codex thread.
Send the first typed message successfully.
Codex responds normally.
Type a second message.
The Send button remains disabled and the second message cannot be submitted.
This also affects existing project threads.
Additional observations

Enter and Ctrl+Enter do not send.
Voice submission still works in the same affected thread.
The same affected threads can still be continued through Remote/mobile.
Regular ChatGPT chats work normally.
Windows Repair and full Reset did not fix the issue.
“Loading scheduled task…” remains stuck indefinitely in affected threads, even when no scheduled task is attached.
View → Open terminal and Ctrl+` do not open the integrated terminal.
The workspace/tool panel itself can still open.
Switching the Windows sandbox to unelevated did not help.
Switching to WSL also did not help.
Potentially relevant log findings
The session transcript contains repeated Git ownership errors:
fatal: detected dubious ownership in repository
The repository is reported as owned by:
DESKTOP-M96NB73/CodexSandboxOffline
(SID ending in -1007)
while the current user is:
DESKTOP-M96NB73/��
(SID ending in -1001)
The filesystem path containing Cyrillic characters itself is logged correctly, e.g.:
C:/Users/Александр/...
so the Unicode corruption appears specific to the Windows user identity string rather than paths in general.
The sandbox log also contains repeated Windows sandbox setup failures with:
Access denied (os error 5)
including failures involving:
C:\Users\Default
and
C:\Users\Default.codex.sandbox\cwd
This setup worked correctly before recent Windows Desktop updates, so this appears to be a regression rather than a longstanding issue with the Windows profile.
I have also submitted in-app feedback with diagnostics enabled for the affected session.

Confirmed working on Windows 11 Pro, ChatGPT Desktop 26.915.31945.
Toggling Settings → Connections → Allow connections Off and back On immediately restored the Send button in affected Codex threads.

Confirmed working on Windows 11 Pro, ChatGPT Desktop 26.915.31945. Toggling Settings → Connections → Allow connections Off and back On immediately restored the Send button in affected Codex threads.

This doesn't work for me. Still logging out and in to fix it temporarily.

Update on September 21 for the installation reported above: the composer blockage is still unresolved on Windows package 26.915.4065.0, bundled app-server 0.155.0-alpha.9.2. CLI remains usable.

Verified outcomes:

Repeating the targeted UI-storage reset did not restore sending.
Uninstalled and reinstalled the official Microsoft Store package. The old MSIX app profile was removed and was not restored. The shared .codex directory, configuration and conversation histories were preserved. The Store installed the same package version; sending still fails. This was not a clean shared Codex configuration test.
Account lookup and thread reads/resumes succeed; no turn/start appears in the current Desktop launch despite the failed user send attempts.
A separate Windows sandbox setup failure was corrected; setupCompleted reported success=true and readiness=ready. This did not fix sending.
Toggling Settings > Connections > Allow connections off/on did not help on this installation. Connections are now left disabled.

Additional confirmed fault, with an UNPROVEN relationship to the composer issue: primary-runtime 26.915.20218 for win32-x64 repeatedly fails checksum verification. This matches #46699. Two independent HTTPS downloads, including a cache-busted CDN MISS, both returned 495163216 bytes with SHA-256 5911799885cacb45d0f95b1f1ed708cca2f5e5664d83291a95bf53643c18c368, while Desktop expects 06266088a7881b8fdc31adaf070e1db070ce4162e8c6137b212334b249d2e9c3. No integrity checks were bypassed and neither archive was installed manually.

Could maintainers provide supported diagnostics for the unresolved composer submission promise/IPC path, and clarify whether missing primary-runtime can gate follow-up submission? No raw transcripts, credentials, private paths or account/conversation identifiers are attached.

U need to set allow connections off and restart the app, also must make sure any project folder ownersid is currentsid, once these criteria are met u should be able to resume send msg in COUPLE of minutes after restarting app, u can then turn on allow connections if u want.

Confirmed working on Windows 11 Pro, ChatGPT Desktop 26.915.31945. Toggling Settings → Connections → Allow connections Off and back On immediately restored the Send button in affected Codex threads.

This doesn't work for me. Still logging out and in to fix it temporarily.

Adding another affected Windows installation, reported on September 23, 2026.

Reported desktop version: 26.917.6896.0.

Reproduction and impact:

Create a new conversation and send the first typed message.
Wait for the assistant response to finish.
Type a follow-up in the same conversation.
The Send button remains disabled and Enter does not submit the message.

The behavior occurs with both Korean and English text. Restarting the app has not resolved it. Creating a new conversation allows the first message to be sent again, so the user has been forced to create a new conversation for each follow-up.

The prior local diagnostic summary reported that the previous response was internally complete and that logs after a restart contained Conversation state not found. This is a reported observation from that diagnostic summary, not a fresh verification in this reporting session. A causal relationship between that error and the disabled Send button has NOT been established.

Expected: after a response completes, the same conversation should accept another typed message.

Please investigate the Windows composer/turn-state recovery path and advise on a supported fix that preserves existing conversations and settings.

Several updates and no fix for me. Can you guys confirm that it's still not working correctly for you?

Still not working

Navigation Menu

Repository navigation

Windows Codex Desktop: Send button becomes disabled after the first successful turn #45307

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Follow-up diagnostic evidence: submission stalls before app-server

Reproduction and expected/actual behavior

Controlled timeline

Strong isolation: another turn succeeds in the SAME task

CLI control and unsuccessful workarounds

Misleading log signal and network correction

Likely investigation area, not a proven root cause

Environment

FIX

Hey peeps 👋 Deleting local memories got Codex working again for me.

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows Codex Desktop: Send button becomes disabled after the first successful turn #45307

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Sep 14, 2026

kunlunliu2007 commented on Sep 14, 2026

Follow-up diagnostic evidence: submission stalls before app-server

Reproduction and expected/actual behavior

Controlled timeline

Strong isolation: another turn succeeds in the SAME task

CLI control and unsuccessful workarounds

Misleading log signal and network correction

Likely investigation area, not a proven root cause

Environment

SproutSquad1 commented on Sep 14, 2026

rcalmamonsblagajna commented on Sep 14, 2026

balajithepassionateqa commented on Sep 14, 2026

shabilizhida commented on Sep 15, 2026

shanshan1231 commented on Sep 16, 2026

shabilizhida commented on Sep 16, 2026

neoteknic commented on Sep 18, 2026

real-scorp22 commented on Sep 19, 2026

balajisivakumaran commented on Sep 19, 2026

FIX

Hey peeps 👋 Deleting local memories got Codex working again for me.

panreyes commented on Sep 19, 2026

alexanderhrncir commented on Sep 19, 2026

sk8pip commented on Sep 20, 2026

sk8pip commented on Sep 21, 2026

alexanderhrncir commented on Sep 21, 2026

neoteknic commented on Sep 21, 2026

xgit-ops commented on Sep 21, 2026

t2bin-eng commented on Sep 23, 2026

alexanderhrncir commented on Sep 24, 2026

Sirius9121 commented on Sep 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions