[Windows Desktop] Existing Local Work chats have Send disabled while new Work chats can send #46763

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Sep 20, 2026
2. github-actions commented on Sep 20, 2026

   

   github-actionsbot

   on Sep 20, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows][26.908.70816] Restored / existing threads keep Send disabled; only a brand-new chat can send (CLI resume works) #45719
   • [Windows Desktop 26.908.70816] Follow-up messages disabled after first completed turn; existing threads cannot send (CLI unaffected) #45626
   • Windows Desktop: Send button disabled after first completed Local Codex/Work turn (native + WSL) #46618

   Powered by Codex Action
3. HovikChan commented on Sep 20, 2026

   

   HovikChan

   on Sep 20, 2026

   Author

   More actions

   Update: I can now reproduce the exact pattern described in #45719. A brand-new Local Work thread can send its first turn successfully, but subsequent turns from the same thread cannot be submitted from Desktop. The same thread remains resumable and writable through Codex CLI.
4. TR2293814813 commented on Sep 20, 2026

   

   TR2293814813

   on Sep 20, 2026

   More actions

   Windows Desktop 26.915.4065.0 (bundled CLI 0.155.0-alpha.9.2): sending a message creates a thread and holds its writer lock, but no rollout is written and the turn never dispatches

   Environment

   • Windows 11, ChatGPT/Codex Desktop 26.915.4065.0 (MSIX, OpenAI.Codex_2p2nqsd0c76g0)
   • Bundled runtime: %LOCALAPPDATA%\OpenAI\Codex\bin\247581e40ee272fb\codex.exe -> 0.155.0-alpha.9.2
   • Agent environment: Windows native, PowerShell

   Observed behaviour

   1. Submitting a message in the Desktop app creates a new thread (visible in the sidebar) and a lock file %USERPROFILE%\.codex\thread-writer-locks\<thread-id>.lock.
   2. No rollout file is created or modified under %USERPROFILE%\.codex\sessions\ for that turn.
   3. The turn never dispatches: while monitoring the configured model endpoint on loopback, zero outbound requests arrive (0 bytes).
   4. The UI stays in a reconnecting/thinking state; sending from existing threads shows Send effectively unusable.
   5. The lock stays held for the lifetime of the app process. Navigating away does not release it; neither does killing the app-server child (the parent respawns it and re-acquires the same lock).
   6. Fully quitting the Desktop app releases the lock immediately.

   Control: same binary, same CODEX_HOME, same config.toml, same endpoint

   • codex.exe exec --skip-git-repo-check (and exec resume <thread-id>) succeeds every single time, and the configured endpoint receives the request.
   • codex.exe exec resume <thread-id> fails only while the Desktop app holds that thread, with:
     thread-store conflict: thread <id> already has an active writer (code -32600)

   Lock semantics verified directly

   • While a <thread-id>.lock is held, any writer attempt fails: failed to open thread writer lock ... (os error 32).
   • Releasing the lock makes the identical command succeed immediately.

   Also observed (may be unrelated, but correlated on this build)

   • error [AppServerConnection] Codex CLI process exited classifiedAsExpected=false code=4294967295 signal=null transport=stdio followed by fatal_error_broadcasted, after which the renderer stays in a failed/reconnecting state even though the app-server is respawned.
   • The three-dot menu can stay on "Loading scheduled tasks..." indefinitely.
   • Windows sandbox: firewall rules block 127.0.0.0/8 for the sandbox account (codex_sandbox_offline_block_loopback_tcp, LocalUser=CodexSandboxOffline), while %USERPROFILE%\.codex\.sandbox\setup_marker.json has "proxy_ports": [], so codex_sandbox_offline_allow_loopback_proxy is never created.

   Expected

   • Submitting a message should persist a rollout and dispatch the turn regardless of which surface holds the thread, or the app should expose an explicit writer handoff / read-only fallback instead of requiring a full app quit.

   Related: #37403, #37450, #46763, #44449, #38150
5. jesusangelurieta-cell commented on Sep 20, 2026

   

   jesusangelurieta-cell

   on Sep 20, 2026

   More actions

   I am experiencing the same issue on the ChatGPT Windows Desktop app with Local Work.
   A new Work conversation can run the first turn successfully, but follow-up messages in the same conversation often cannot be submitted. Creating a new Work conversation allows me to continue temporarily.
   My local Codex logs repeatedly show:
   Received turn/started for unknown conversation
   Received turn/completed for unknown conversation
   OpenAI Support reviewed my description and advised me to report this in the Codex GitHub repository. I have preserved the original .codex session data.
   I have a sanitized diagnostic file containing only timestamps and these unknown conversation messages, with conversation IDs and other private content removed.

   Codex-error-unknown-conversation.txt
6. TR2293814813 commented on Sep 20, 2026

   

   TR2293814813

   on Sep 20, 2026

   More actions

   Thanks for the sanitized log — it matches what I captured locally on the same build, and it points at the actual defect.

   Your 21 lines are all Received turn/started/completed for unknown conversation. I have the same signature in my own desktop log, with the conversation id intact:

   2026-09-20T05:56:54.997Z error [electron-message-handler]
     Received turn/started for unknown conversation
     conversationId=01a0bd63-8d7b-7641-948b-4226b8c80fd6
     rendererWebContentsId=1 rendererWindowFocused=true rendererWindowVisible=true
   

   That line is the crux: the app-server broadcasts turn lifecycle events for a conversation the renderer does not have registered. Because the two sides disagree on conversation identity, the turn is never adopted by the writer path, so:

   1. no rollout file is created under %USERPROFILE%\.codex\sessions\ for that turn;
   2. the turn never dispatches (no outbound model request at all — verified by watching the configured loopback endpoint: 0 bytes);
   3. the thread's writer lock under %USERPROFILE%\.codex\thread-writer-locks\<thread-id>.lock stays held for the lifetime of the app process;
   4. the UI drops to the read-only fallback, i.e. Send disabled — consistent with the behaviour introduced by Show read-only conversations when resume encounters an active writer #43253.

   Two control experiments that isolate this from networking or configuration, on the same machine, same CODEX_HOME, same config.toml:

   • codex.exe exec --skip-git-repo-check (and exec resume <thread-id>) succeeds every time, and the endpoint does receive the request.
   • While the Desktop app has the thread open, the identical command fails with thread-store conflict: thread <id> already has an active writer (code -32600). The lock is held by the app's own app-server: an exclusive open of <thread-id>.lock fails while it runs, and succeeds the moment the app is fully quit.

   Two details that may help maintainers narrow it down further:

   • Killing only the codex app-server child is not a fix: the parent respawns it and the new child re-acquires the same writer lock. Only a full app quit releases it.
   • It is not limited to Work mode. On my machine a brand-new thread in Codex mode also fails on its first turn (lock created, no rollout written, no request dispatched), so "create a new Work conversation" is only a partial workaround rather than a reliable one.
   • Possibly related on Windows: the sandbox firewall installs codex_sandbox_offline_block_loopback_tcp for LocalUser=CodexSandboxOffline (RemoteAddress 127.0.0.0/8) while %USERPROFILE%\.codex\.sandbox\setup_marker.json has "proxy_ports": [], so the documented "(Except Proxy)" exception codex_sandbox_offline_allow_loopback_proxy is never created.

   Requested improvements, on top of a fix for the identity mismatch: include owner/lease information in the -32600 conflict (surface, pid, acquisition time), and expose an explicit release/handoff (thread/release, thread/unload) instead of relying on a full app quit.

   Related: #37403, #37450, #44449, #38150.