[Windows][26.908.70816] Restored / existing threads keep Send disabled; only a brand-new chat can send (CLI resume works)

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

26.908.70816 (updated from 26.908.40834)

What subscription do you have?

Pro20x

What platform is your computer?

Windows 11 x64 Agent environment: Windows native (previously WSL) Integrated terminal: PowerShell runCodexInWindowsSubsystemForLinux = false

What issue are you seeing?

After updating Codex Desktop, the composer Send button stays gray/disabled.

This is not limited to WSL. I switched the agent to Windows native and set the integrated terminal to PowerShell. New chats can send; any conversation restored after Quit still cannot.

Pattern that reproduces every time:

1. Create a new chat → first message sends (e.g. hi) and gets a reply.
2. Fully Quit Codex (tray icon included) and reopen.
3. The chat from step 1 now has a disabled Send button. Typing works; Enter / click Send does nothing. No turn/start is issued.
4. The only way to send from Desktop again is to create another new chat. After the next Quit, that chat locks too.

So: Desktop can start a thread, but cannot continue a restored thread.

The same locked Desktop thread can be resumed and continued in Codex CLI (codex resume) once Desktop has fully quit. CLI is unaffected. This matches the Desktop-only composer regression.

What steps can reproduce the bug?

1. Codex Desktop 26.908.70816 on Windows, agent = Windows native, terminal = PowerShell.
2. New chat, send hi, wait until the turn completes.
3. Tray → Quit. Confirm no Codex/ChatGPT processes remain.
4. Reopen Codex, open that same chat.
5. Type a follow-up and try Send.

Actual: Send stays gray/disabled. Message never submits.
Expected: After the previous turn is completed, Send enables and a new turn/start is sent.

Also seen:

• While Agent was still WSL: Send gray on new and existing chats.
• After switching to native: new chat first message works; restored chats do not.
• CODEX_CLI_PATH was being rewritten into config.toml on Quit (under [mcp_servers.node_repl.env], pointing at ...\OpenAI\Codex\bin\<hash>\codex.exe). Deleting that line restores new-chat send; it does not restore send on chats reopened after Quit. Native/WSL and this path are separate from the restored-thread lock.

What is the expected behavior?

No response

Additional information

Tried (did not fix restored-thread Send):

• Switch WSL → Windows native; integratedTerminalShell = "powershell"
• Delete CODEX_CLI_PATH (new chats work; restored chats still gray)
• Fully Quit / restart; do not reopen old WSL/\\wsl$\ projects
• Pad a new chat with one message, then switch back to the old thread
• Same thread continues in CLI after Desktop is closed

Not a login/quota/network issue: the new-chat path works on the same account, same machine, same config. CLI resume of the locked thread also works.

Related: #44102 #45069 #45404 #45626 #44295

Logs I can attach if useful: Desktop logs under %LOCALAPPDATA%\Packages\OpenAI.Codex_*\LocalCache\Local\Codex\Logs\ (search markedStreaming, loading-local-config, turn/start).

Start by reproducing the restored-thread case and inspect the Desktop logs under %LOCALAPPDATA%\Packages\OpenAI.Codex_*\LocalCache\Local\Codex\Logs, especially entries for markedStreaming, loading-local-config, and turn/start. Trace the restored conversation's composer state and compare it with a new chat; done means Send enables after a completed turn and a follow-up turn/start is issued, while CLI resume remains unaffected.