You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Windows Desktop][26.908.40834] Second prompt cannot be sent after first successful turn, send button becomes disabled while CLI works normally #45886
I spent several hours troubleshooting this regression as a paid user, including testing proxy modes, GPU-related possibilities, process status, runtime components, and comparing Desktop behavior with CLI behavior.
The investigation confirmed that the backend/session are working normally because Codex CLI supports multiple turns correctly. The issue appears limited to the Desktop UI after the first completed turn.
Since this regression significantly affected productive usage time for paid users, I would appreciate it if the team could consider a courtesy usage reset or another form of compensation for affected users, if possible.
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.
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.
It really does work! Thank you so much! I had the same issue and discussed it with ChatGPT as well. It told me to wait for an update. I tried completely reinstalling ChatGPT using PowerShell, but it only worked for a while. Then I downloaded a previous version, and it worked perfectly. I thought it was fixed, but Windows automatically updated it again and the problem came back. Classic Microsoft! 😅
Yes, please try logging out and logging back in. I didn’t change any of my account info, but it worked for me.
Additional Windows desktop reproduction on package OpenAI.Codex 26.908.9136.0 (ChatGPT.exe), with bundled codex-cli 0.154.0-alpha.6.2. Package version was inspected locally; About-dialog version was not separately recorded.
The affected user reports roughly two weeks of blocked follow-up messaging. On the latest reproduction:
Open an existing task, type a message and attempt to send.
Send becomes gray with a revolving indicator, but no reply appears.
Switch tasks: the indicator stops, but the draft remains in the text box and Send remains disabled.
Backend diagnostic messages queued through the CLI completed and produced replies while ordinary desktop submission remained blocked. This localizes the observed difference to the submission paths; it does not establish a root cause or exclude authentication issues.
Additional isolation performed on September 17, 2026:
Repeated restarts did not resolve it.
With the app stopped, its desktop browser/profile storage was moved to a preserved backup, then the app was relaunched. Newly created browser storage and subsequent writes were verified. The user reproduced the same unsent-message failure afterward.
Chat history, Codex configuration and global settings were intentionally retained. This was NOT a full clean-account/profile test, and a complete sign-out/sign-in has not been verified.
Native browser integration registrations were repaired, and a broken optional local MCP entry was disabled. Neither resolved desktop sending.
Earlier local diagnostic checks passed authentication, app-server/WebSocket connectivity and database integrity, but these checks do not prove that all desktop authentication or composer prerequisites are healthy.
The user also reports intermittent plugin loading (especially Computer Use), older-task hangs and unavailable voice; those symptoms may be separate and were not all retested after the storage replacement.
Browser and alternate-network reproduction have not been tested. No current internal submit-block reason or definitive root cause was captured. The sign-out/sign-in recovery mentioned above has not yet been tested in this installation.
Please include this newer package reproduction and the failed browser-storage replacement in the investigation. A supported way to recover or diagnose the composer without deleting task history would help. No account identifiers, email, private task/project details, filesystem usernames, raw logs or session contents are included here.
Update (2026-09-17): the issue is no longer reproducing for me today, and multi-turn conversations are currently working normally again.
Important detail: the Codex Desktop About dialog still shows the same version as before:
Powered by Codex & OWL
Version: 26.908.40834
Released: 2026-09-12
So the recovery occurred without an observed desktop version change. I have not yet identified what state change caused the recovery, so I do not want to claim a root cause. This may be useful in determining whether the issue is intermittent or related to session/authentication/client state rather than a fixed build.
I am keeping the issue open for now in case it recurs or a maintainer wants additional diagnostics.
The same Windows Codex Desktop problem returned after appearing normal the previous day. The app version is still 26.908.40834. The failure remains intermittent rather than permanently resolved: follow-up messages can again become unsendable/greyed out after a successful turn.
This recurrence suggests the prior recovery was temporary and should not be treated as a confirmed fix. Please keep this issue open for investigation.
Without restarting Codex, without restarting the app-server, and without restarting the renderer, I cancelled and refetched only the two stuck read-only codex-home queries.
Immediately afterward, the normal bottom composer started sending successfully again in the same affected conversation.
A separate test also showed that restarting only the main Renderer restored normal composer sending for subsequent messages, which is consistent with the stuck renderer/query-state diagnosis.
Conclusion
On this machine the observed chain was:
codex-home stuck pending/fetching
→ managed worktree state stuck at codex-home-loading
→ localWorkspaceMaterialization = loading
→ submitBlockReason = loading-local-config
→ Send disabled / follow-up messages cannot be submitted.
Targeted cancel + refetch of the two stuck codex-home queries cleared the condition and restored normal sending.
Marking this issue resolved from my side because the local failure is now understood and recoverable. The product-side startup/query hang may still need a permanent fix to prevent recurrence.
Same symptom as OP, with one detail that may help narrow it down:
this does NOT reproduce for a classmate running the identical build.
Environment
OS: Windows 11 x64 (10.0.26200)
Codex Desktop: 26.917.51856
Network: Clash TUN mode (CLI works fine over the same path)
Workspace: WSL2 project + native Windows projects, both affected
Symptom
Turn 1 succeeds normally; after the response completes, the composer
accepts text but the Send button stays greyed out and the message
cannot be submitted
Ctrl+Enter also does nothing
Intermittent: a restart sometimes temporarily restores it, then it
breaks again after a few turns
The Codex CLI on the same machine, same account, same network
completes multiple consecutive turns without issue
What makes this case different from other reports
A classmate on the SAME build (26.917.51856), same network conditions,
sends follow-up messages in the same conversation normally. So this
does not look like a build-wide regression. If the composer state is
the same code for everyone, the differentiator may be local state.
Local state worth checking on my machine:
[windows] sandbox = "elevated" and the
codex-windows-sandbox-service process running
Since last update, the issue is recurring again. now I cant even see the desktop. I tried to use command line to open codex desktop which make it work somehow but as soon as I close it, next time I cant open the desktop. the freeze is frequent now
Activity
github-actions commentedon Sep 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
molijeur-blip commentedon Sep 16, 2026
Additional reproduction details:
I tested further:
This confirms the issue is limited to Codex Desktop UI state handling after the first turn, rather than backend/session/network problems.
molijeur-blip commentedon Sep 16, 2026
Additional note regarding impact:
I spent several hours troubleshooting this regression as a paid user, including testing proxy modes, GPU-related possibilities, process status, runtime components, and comparing Desktop behavior with CLI behavior.
The investigation confirmed that the backend/session are working normally because Codex CLI supports multiple turns correctly. The issue appears limited to the Desktop UI after the first completed turn.
Since this regression significantly affected productive usage time for paid users, I would appreciate it if the team could consider a courtesy usage reset or another form of compensation for affected users, if possible.
Thank you for investigating this issue.
shanshan1231 commentedon Sep 16, 2026
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.
cyheise commentedon Sep 16, 2026
It really does work! Thank you so much! I had the same issue and discussed it with ChatGPT as well. It told me to wait for an update. I tried completely reinstalling ChatGPT using PowerShell, but it only worked for a while. Then I downloaded a previous version, and it worked perfectly. I thought it was fixed, but Windows automatically updated it again and the problem came back. Classic Microsoft! 😅
Yes, please try logging out and logging back in. I didn’t change any of my account info, but it worked for me.
rmak78 commentedon Sep 16, 2026
Additional Windows desktop reproduction on package OpenAI.Codex 26.908.9136.0 (ChatGPT.exe), with bundled codex-cli 0.154.0-alpha.6.2. Package version was inspected locally; About-dialog version was not separately recorded.
The affected user reports roughly two weeks of blocked follow-up messaging. On the latest reproduction:
Backend diagnostic messages queued through the CLI completed and produced replies while ordinary desktop submission remained blocked. This localizes the observed difference to the submission paths; it does not establish a root cause or exclude authentication issues.
Additional isolation performed on September 17, 2026:
The user also reports intermittent plugin loading (especially Computer Use), older-task hangs and unavailable voice; those symptoms may be separate and were not all retested after the storage replacement.
Browser and alternate-network reproduction have not been tested. No current internal submit-block reason or definitive root cause was captured. The sign-out/sign-in recovery mentioned above has not yet been tested in this installation.
Please include this newer package reproduction and the failed browser-storage replacement in the investigation. A supported way to recover or diagnose the composer without deleting task history would help. No account identifiers, email, private task/project details, filesystem usernames, raw logs or session contents are included here.
molijeur-blip commentedon Sep 17, 2026
Update (2026-09-17): the issue is no longer reproducing for me today, and multi-turn conversations are currently working normally again.
Important detail: the Codex Desktop About dialog still shows the same version as before:
So the recovery occurred without an observed desktop version change. I have not yet identified what state change caused the recovery, so I do not want to claim a root cause. This may be useful in determining whether the issue is intermittent or related to session/authentication/client state rather than a fixed build.
I am keeping the issue open for now in case it recurs or a maintainer wants additional diagnostics.
molijeur-blip commentedon Sep 18, 2026
Reopening: the issue has recurred on 2026-09-18.
The same Windows Codex Desktop problem returned after appearing normal the previous day. The app version is still 26.908.40834. The failure remains intermittent rather than permanently resolved: follow-up messages can again become unsendable/greyed out after a successful turn.
This recurrence suggests the prior recovery was temporary and should not be treated as a confirmed fix. Please keep this issue open for investigation.
molijeur-blip commentedon Sep 18, 2026
Resolved locally with a targeted recovery, and the failure chain was reproduced directly on this machine.
Runtime evidence
While the normal bottom composer was stuck:
windowwith URLapp://-/index.html.disabled: true.submitBlockReason = "loading-local-config"localWorkspaceMaterialization = "loading"isResponseInProgress = falseisResumePending = falseThe renderer's TanStack Query cache then showed:
Recovery test
Without restarting Codex, without restarting the app-server, and without restarting the renderer, I cancelled and refetched only the two stuck read-only
codex-homequeries.Before:
After:
Immediately afterward, the normal bottom composer started sending successfully again in the same affected conversation.
A separate test also showed that restarting only the main Renderer restored normal composer sending for subsequent messages, which is consistent with the stuck renderer/query-state diagnosis.
Conclusion
On this machine the observed chain was:
codex-homestuck pending/fetching→ managed worktree state stuck at
codex-home-loading→
localWorkspaceMaterialization = loading→
submitBlockReason = loading-local-config→ Send disabled / follow-up messages cannot be submitted.
Targeted cancel + refetch of the two stuck
codex-homequeries cleared the condition and restored normal sending.Marking this issue resolved from my side because the local failure is now understood and recoverable. The product-side startup/query hang may still need a permanent fix to prevent recurrence.
cali-mori commentedon Sep 25, 2026
Same symptom as OP, with one detail that may help narrow it down:
this does NOT reproduce for a classmate running the identical build.
Environment
Symptom
accepts text but the Send button stays greyed out and the message
cannot be submitted
breaks again after a few turns
completes multiple consecutive turns without issue
What makes this case different from other reports
A classmate on the SAME build (26.917.51856), same network conditions,
sends follow-up messages in the same conversation normally. So this
does not look like a build-wide regression. If the composer state is
the same code for everyone, the differentiator may be local state.
Local state worth checking on my machine:
codex-windows-sandbox-service process running
unified-computer-use plugins enabled
Already ruled out (all ineffective)
Happy to provide logs or config diff against the working machine if useful.
rmak78 commentedon Sep 27, 2026