Skip to content

Windows Desktop: first prompt succeeds, second message cannot be sent; reinstall only fixes it temporarily #45797

Open
Open
Windows Desktop: first prompt succeeds, second message cannot be sent; reinstall only fixes it temporarily#45797
Labels
appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@BilibiliSZdaomei
BilibiliSZdaomei
opened on Sep 15, 2026

Summary

I am seeing a recurring Codex Desktop issue on Windows where a conversation works for exactly one turn, but after the first response completes I can no longer send another message in the same conversation.

This has now happened to me multiple times. Reinstalling Codex Desktop fixed it temporarily once, but the same problem returned again on September 15, 2026.

Environment

  • OS: Windows 10 (64-bit)
  • App: Codex Desktop for Windows
  • Date reproduced again: September 15, 2026
  • The issue affects existing conversations after the first successful turn

Steps to reproduce

  1. Open Codex Desktop on Windows.
  2. Open a project/conversation (or start a new one).
  3. Send the first prompt.
  4. Wait for Codex to finish responding normally.
  5. Type a second message in the same conversation and try to send it.

Actual behavior

The first prompt and response work normally, but the second message cannot be sent / does not start a new turn. The conversation effectively becomes unusable after one successful exchange.

In my case, reinstalling the Windows desktop app previously restored normal behavior, but only temporarily. The bug has now returned, which makes it look more like a recurring Desktop client / renderer state issue than corrupted project or conversation data.

Expected behavior

After the first response completes, I should be able to continue sending follow-up messages in the same conversation normally.

What I have observed

  • First turn: works normally.
  • Second/follow-up message: cannot be sent.
  • Reinstall: previously fixed the problem temporarily.
  • The problem later returned without intentionally modifying my Codex conversation data.

Related reports

This appears very similar to several recent Windows Desktop reports, including:

I am opening another report to confirm that this is still reproducible on a separate Windows installation as of September 15, 2026.

I can provide additional logs or run specific diagnostics if that would help identify whether this is the same loading-local-config / renderer state problem described in some of the related issues.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    on Sep 15, 2026

  2. github-actions commented on Sep 15, 2026

    @github-actions
    github-actionsBot
    on Sep 15, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. BilibiliSZdaomei commented on Sep 15, 2026

    @BilibiliSZdaomei
    BilibiliSZdaomei
    on Sep 15, 2026 – with ChatGPT Codex Connector
    Author

    Additional reproduction and workaround confirmation on Windows package OpenAI.Codex 26.908.9136.0 (September 15, 2026).

    The same user-visible failure is still reproducible on this newer build:

    1. Open a conversation in Codex Desktop for Windows.
    2. Send the first prompt; it completes normally.
    3. Try to send a follow-up message in the same conversation.
    4. The follow-up cannot be submitted / no new turn starts.

    I then tested the renderer-restart workaround without reinstalling Codex, clearing caches, resetting .codex, or deleting any conversation data.

    Using PowerShell, I listed the running ChatGPT.exe renderer processes (--type=renderer). The renderer corresponding to the main Codex window was the clearly dominant renderer by working set / CPU in this session. I terminated only that renderer process with Stop-Process -Id <PID> -Force while the previous model turn was already complete and no task was actively running.

    Observed result:

    • The Codex main window briefly went white and rebuilt itself automatically.
    • The same existing conversation remained available after the renderer restarted.
    • The previously blocked follow-up message could then be sent successfully in that same conversation.
    • No app reinstall, app restart, cache wipe, .codex reset, login reset, or conversation migration was needed.

    This strongly matches the renderer/local-initialization stuck-state behavior described in #44342 and #45069, and confirms that the issue is still present on 26.908.9136.0.

    Important limitation: identifying the main renderer by highest memory/CPU is only what worked in this specific session and should not be treated as a generally safe identification method across all builds/windows. A supported in-app renderer reload / local-state retry action would still be preferable.

  4. shanshan1231 commented on Sep 16, 2026

    @shanshan1231
    shanshan1231
    on Sep 16, 2026

    I finally fixed this issue on my machine.

    My symptom was exactly the same: the first message in a new Codex conversation worked, but the second message would stay stuck indefinitely.

    In my case, the root cause turned out to be stale authentication. My Google account password had been changed, but Codex Desktop still appeared to be logged in and did not ask me to authenticate again.

    After changing/resetting the password and then fully signing out of Codex and signing back in with ChatGPT/Google, multi-turn conversations immediately started working again.

    So if you have this issue, I recommend trying a full logout and re-login, especially if your Google/OpenAI account credentials were changed recently. The app may appear authenticated even though its cached authentication state is no longer valid.

  5. o-khard commented on Sep 17, 2026

    @o-khard
    o-khard
    on Sep 17, 2026

    I tried relogging in - issue persisted. So relogging isn't a universal solution.

  6. Nokanokanoka commented on Sep 18, 2026

    @Nokanokanoka
    Nokanokanoka
    on Sep 18, 2026 – with ChatGPT Codex Connector

    Still reproducible on a newer Windows Desktop build.

    Environment:

    • Windows 11 Pro x64, OS build 26200
    • Codex Desktop: 26.915.3509.0
    • Codex CLI / doctor: 0.155.0
    • ChatGPT authentication

    Reproduction:

    1. Start a new Codex chat.
    2. Send the first prompt — it sends and completes normally.
    3. Type a second message in the same chat.
    4. The second message cannot be submitted / no new turn starts.
    5. Creating another new chat allows exactly one successful message again, then the same failure repeats.

    Also affects existing chats.

    Troubleshooting already tried:

    • Fully quit/restarted the app
    • Confirmed app is current
    • Windows app Repair
    • Windows app Reset
    • Reproduces after reset
    • codex doctor --all: 21 ok, 1 idle, 2 notes, 2 warn, 0 fail
    • State DB, thread history DB, queue DB all report integrity OK
    • Auth is configured
    • WebSocket connection succeeds with HTTP 101
    • Provider endpoints are reachable

    Relevant desktop log behavior:

    • The first turn reaches turn-complete normally and the desktop notification is emitted.
    • After that, attempting a follow-up does not appear to create a new turn/start request.
    • Around the completed turn there are IPC warnings such as:
      • Received broadcast but no handler is configured method=thread-stream-following-changed
      • Received broadcast but no handler is configured method=thread-read-state-changed

    This looks like a Windows Desktop renderer/thread-state synchronization issue: backend turn completion succeeds, but the composer does not become able to start the next turn.

    I can provide additional sanitized logs if useful.

  7. GoMaaars commented on Sep 20, 2026

    @GoMaaars
    GoMaaars
    on Sep 20, 2026

    Same root cause as #44342: the renderer's first batch of vscode/* local requests (codex-home included) gets its responses dropped during startup and nothing retries them. Re-issuing those queries after startup recovers in milliseconds without reloading the window. Details and a small MIT workaround script (manual + optional auto-run on app start) here: https://github.com/GoMaaars/codex-desktop-send-button-fix — happy to add more traces if useful.

  8. shanshan1231 commented on Sep 21, 2026

    @shanshan1231
    shanshan1231
    on Sep 21, 2026

    与#44342 的根本原因相同：渲染器启动时发送的第一批vscode/*本地请求（codex-home包括已发送的请求）的响应被丢弃，并且没有任何机制会重试。启动后重新发送这些请求可以在几毫秒内恢复响应，无需重新加载窗口。详情以及一个小型 MIT 许可的解决方法脚本（手动运行 + 可选的开机自动运行）请参见：https://github.com/GoMaaars/codex-desktop-send-button-fix — 如果需要，我很乐意提供更多跟踪信息。

    太专业了！这个问题在我电脑上出现了好久，我之前的解决办法就是重新登录codex和网页端的账号，就能恢复正常（后续也会复现问题，但是按照这种重新登录的办法也能解决），但是我一直没有溯源问题的根本，我大概清楚问题是出现在哪里，今天终于一探究竟了。不愧是MIT

  9. Sebastian-Habenicht commented on Sep 21, 2026

    @Sebastian-Habenicht
    Sebastian-Habenicht
    on Sep 21, 2026

    Additional reproduction on Windows desktop:

    Windows 11 Pro x64, OS build 26200.9457
    Codex Desktop: 26.915.31945

    • In a brand-new Local Work task outside any project, the first message sends and the response completes normally.
    • A second message can be typed, but Send remains dimmed. Pressing Enter or clicking Send shows a working spinner, which remains until the session is left; no new message or turn appears.
    • Leave this session, than return back -> default Send icon in dimmed state is visible, entered message still visible; no new message or turn appears.
    • The task was confirmed idle after the first response, with only that first exchange in its history.
    • The same behavior occurs in an existing task after moving it into a project. Restarting the desktop app did not help.
    • Typed messages in regular chats still send normally. Voice mode in the affected Work task remains available when the composer is empty.

    This matches the first-turn-only behavior reported here and adds the brief spinner and unaffected regular-chat/voice observations.

    EDIT:

    • Also noted: When hovering the mouse over it, the first message shows timestamp (e.g. "Tuesday 3:§7PM") and copy-message action. All my subsequent messages (created via Voice Chat, which is still possible) display no such information or actions whatsoever.

  10. val235 commented on Sep 24, 2026

    @val235
    val235
    on Sep 24, 2026

    Reproducing this across my machines as of September 24, 2026. On one affected machine: Windows 11 Pro x64, OS build 26200, Codex Desktop 26.917.9434.0.

    A new conversation may accept its first prompt, but follow-ups do not send; existing conversations are also blocked. Remote can still continue the conversation while the Windows desktop composer cannot. Restarting a ChatGPT.exe renderer, which previously helped, no longer restores sending for me.

    On the affected machine, codex doctor --all reports healthy local databases, successful app-server initialization, and a working model connection. I have not established where the desktop send fails. Please investigate a durable fix and provide a supported recovery action that preserves drafts and conversations.

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