Skip to content

[Windows Desktop][26.908.40834] Second prompt cannot be sent after first successful turn, send button becomes disabled while CLI works normally #45886

Closed

Description

@molijeur-blip

Environment

  • OS: Windows 11 x64
  • Codex Desktop version: 26.908.40834
  • Codex CLI version: 0.154.0-alpha.6.2
  • Installation: OpenAI Codex Desktop

Bug description

After the first successful conversation turn, Codex Desktop becomes unable to send any further messages.

The first prompt works normally:

  1. Create a new chat
  2. Enter a message
  3. Send successfully
  4. Codex generates a response normally

After the response is completed:

  1. Enter a second message
  2. The input text appears normally in the composer
  3. The send button remains grey/disabled
  4. Clicking it does nothing
  5. Ctrl+Enter does nothing
  6. Ctrl+A does not behave normally in the composer

The issue reproduces in:

  • New chats
  • Existing conversations

Expected behavior

After the first response finishes, the composer should become active again and allow sending the next message.

Actual behavior

The composer visually accepts text, but Codex Desktop behaves as if there is no valid input. The send button remains disabled and no new turn starts.

Reproduction steps

  1. Open Codex Desktop on Windows
  2. Create a new chat
  3. Send any message
  4. Wait until Codex finishes responding
  5. Type another message

Result: The send button becomes grey and the message cannot be submitted.

Additional debugging information

The backend appears healthy:

  • codex.exe app-server is running normally.
  • CLI works correctly.

CLI test:

codex-cli 0.154.0-alpha.6.2

Verified:

  • CLI first prompt works
  • CLI second prompt works

This suggests the issue is likely limited to Desktop UI/composer state management rather than backend/session/network.

Process information

Desktop launches:

codex.exe ... app-server

Process status:

codex.exe
Responding: True

Notes

I tested:

  • Different proxy modes
  • Network changes
  • GPU-related troubleshooting
  • Restarting processes

The issue consistently reproduces only in Desktop UI after the first completed turn.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    on Sep 16, 2026
  2. molijeur-blip commented on Sep 16, 2026

    @molijeur-blip
    Author

    Additional reproduction details:

    I tested further:

    • New chat: first message works normally.
    • After the first response completes, the second message cannot be sent.
    • The send button becomes grey even though text exists in the composer.
    • Ctrl+Enter does not submit.
    • Ctrl+A does not behave normally in the composer.
    • CLI works normally for multiple turns.

    This confirms the issue is limited to Codex Desktop UI state handling after the first turn, rather than backend/session/network problems.

  3. molijeur-blip commented on Sep 16, 2026

    @molijeur-blip
    Author

    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.

  4. shanshan1231 commented on Sep 16, 2026

    @shanshan1231

    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.

  5. cyheise commented on Sep 16, 2026

    @cyheise

    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.

    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.

  6. rmak78 commented on Sep 16, 2026

    @rmak78

    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:

    1. Open an existing task, type a message and attempt to send.
    2. Send becomes gray with a revolving indicator, but no reply appears.
    3. 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.

  7. molijeur-blip commented on Sep 17, 2026

    @molijeur-blip
    Author

    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.

  8. molijeur-blip commented on Sep 18, 2026

    @molijeur-blip
    Author

    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.

  9. molijeur-blip commented on Sep 18, 2026

    @molijeur-blip
    Author

    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:

    • The main Codex window was identified as the Electron window with URL app://-/index.html.
    • The Send button was actually disabled: true.
    • React state in the affected renderer showed:
      • submitBlockReason = "loading-local-config"
      • localWorkspaceMaterialization = "loading"
      • isResponseInProgress = false
      • isResumePending = false

    The renderer's TanStack Query cache then showed:

    ["vscode","codex-home","{\"hostId\":\"local\"}"]
      status=pending
      fetchStatus=fetching
      hasData=false
      error=null
    
    ["vscode","codex-home"]
      status=pending
      fetchStatus=fetching
      hasData=false
      error=null
    
    ["git","local","managed-worktree-state","codex-home-loading","<workspace>"]
      status=pending
      fetchStatus=idle
      hasData=false
      error=null
    

    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-home queries.

    Before:

    status=pending
    fetchStatus=fetching
    hasData=false
    error=null
    

    After:

    status=success
    fetchStatus=idle
    hasData=true
    error=null
    

    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.

  10. cali-mori commented on Sep 25, 2026

    @cali-mori

    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
    • desktop: followUpQueueMode = "steer"
    • mcp_servers.node_repl enabled, plus bundled browser / computer-use /
      unified-computer-use plugins enabled

    Already ruled out (all ineffective)

    • Restarting the app and the PC
    • Moving the installation between C: and D: multiple times, both directions
    • Uninstalling and reinstalling the desktop app
    • Clearing cache/temp state under ~/.codex
    • CODEX_CLI_PATH verified: points to an existing, valid CLI directory
    • Node/npm environment verified healthy; account verified

    Happy to provide logs or config diff against the working machine if useful.

  11. rmak78 commented on Sep 27, 2026

    @rmak78
    Image 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions