Windows Desktop: second prompt never sends in a thread inside a registered project; reproduces on fully wiped machine (26.915.4065.0)

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

26.915.4065.0 (client 26.915.31945, build 9922, core 0.155.0). Same on 26.908.9136.0 and 26.915.3509.0.

What subscription do you have?

ChatGPT Personal Pro Plan ($200 mo.)

What platform is your computer?

Windows 11 x64 (single Windows account, MSIX install from chatgpt.com/download)

What issue are you seeing?

Turn 1 in a new thread completes and renders. Prompt 2 sits in the composer with Send disabled and a spinner by the model picker for the life of that window. No crash, no Event 1002. Quit and relaunch gives exactly one more turn.

This is the same symptom as #40968 and #41081, still present on 26.915.4065.0, and I can add two things those threads do not have: it reproduces on a machine with every trace of Codex removed, and the client log location plus the exact line where the send path stops.

Reproduces after a full wipe. Three fresh installs today. Before the third I removed: app package (all users), CodexSandboxService, CodexSandboxOffline/Online users, their profile folders and ProfileList entries, CodexSandboxUsers group, codex_sandbox firewall rules, %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0, %LOCALAPPDATA%\OpenAI\Codex, ~/.codex, ~/.cache/codex-runtimes, ~/.agents, ~/.sbx-denybin, HKLM\Software\OpenAI, the Chrome native messaging host com.openai.codexextension, the Credential Manager entry secrets|<id>.codex, temp files; rebooted; installed; signed in. No AGENTS.md, no rules, no custom MCP servers, no user config. First thread inside a registered project hangs after turn 1.

Client log (MSIX virtualized; the AppData\Local\Codex\Logs path the app reports does not exist):
%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\YYYY\MM\DD\codex-desktop-<session>-<pid>-t0-i1-*.log

Working second turn (01:53:26Z): configRequirements/read -> [electron-message-handler] Reasoning summary turn-start config resolved -> turn/start.

Hung sessions (six of them): each press of Send logs configRequirements/read twice and nothing follows. turn-start config resolved never logs, turn/start is never issued. The app-server log (~/.codex/logs_2.sqlite) shows turn/completed for turn 1 delivered to the client and no later request on that thread. The core is idle; codex.exe in a terminal on the same core and account runs unlimited turns.

Also: every thread on gpt-5.6-sol and gpt-6-astra starts with two client-injected developer messages (You are /root, the primary agent in a team of agents and <multi_agent_mode>) while codex features list on the bundled core reports multi_agent false, multi_agent_v2 false. Right after turn/start the client logs Received turn/started for unknown conversation for one or two thread ids that are not the user's thread, then turn/completed for unknown conversation. gpt-5.6-luna threads have neither, and Luna is the one model that survived a shell-command turn inside a registered project.

What steps can reproduce the bug?

1. Fresh install of Codex Desktop on Windows, sign in, quit. Nothing in ~/.codex beyond what the installer wrote.
2. Register one project (an empty folder is enough).
3. Quit and relaunch so the project is registered at launch.
4. New thread in that project, model gpt-5.6-sol (any effort) or gpt-6-astra.
5. Prompt 1: Run a shell command to count the files in this folder and tell me the number. Completes correctly.
6. Prompt 2: test. Never sends.

Observations across the three fresh installs today (UTC):

Time	Model, effort	Thread location	Turn 1	Prompt 2
01:53	gpt-5.6-sol high	registered project	"testing" (no reasoning, no tool)	sent
02:01	gpt-5.6-sol high	registered project	read skills via shell	never sent
02:06	gpt-5.6-sol high	registered project	shell command	never sent
02:15	gpt-5.6-luna low	registered project	shell command	sent
02:19	gpt-5.6-sol low	registered project	shell command	never sent
02:29	gpt-6-astra	registered project	"test"	never sent
02:37	gpt-5.6-sol medium	project added live in that session	four one-word turns	all sent
02:38	gpt-5.6-sol medium	same project after relaunch	"test"	never sent
02:49	gpt-6-astra medium	projectless (Documents\Codex)	two turns	both sent
02:50	gpt-6-astra medium	registered project	one turn	never sent
02:52	gpt-6-astra medium	projectless	working	working

Earlier today on my original state the same variable was mapped over ~50 cycles: zero registered projects at launch works every time; any registered project at launch, including a fresh 29-file folder, hangs.

Hung session ids from today: 01a0b767-4ec8-7a82-957b-9324ec7070aa, 01a0b76a-8494-7a30-a4d1-b75d1b97fdf9, 01a0b776-9764-7e32-b5eb-733306d6b394, 01a0b787-e5be-7241-8905-e9eac33e4515. Working: 01a0b75e-2e04-7cc1-aef6-54de5ed3d7ba, 01a0b772-4248-7271-aef9-95948f44c27f (luna).

What is the expected behavior?

Prompt 2 sends in a thread inside a registered project the same way it does in a projectless thread, on every model. The composer returns to idle after turn/completed, regardless of whether turn 1 ran a command or produced reasoning.

Additional information

Ruled out, with evidence: Windows elevated sandbox (rebuilt with codex sandbox setup --elevated --current-user, whoami inside codex exec -s read-only returns the sandbox user; hang unchanged before and after). OneDrive (stopped and disabled; also reproduces with a project rooted in Documents\Codex). Project size (empty folder reproduces). AGENTS.md, rules, hooks, MCP servers, skills (reproduces with none present). Approval mode ("Ask for approval" default and "Full access" both hang). Machine state (full wipe and reboot, list above).

Config at the time of the hung sessions is the app-written default: notify pointing at the bundled codex-computer-use.exe turn-ended, [windows] sandbox = "elevated", all bundled plugins enabled. Adding [features] multi_agent = false changed nothing.

Workaround in use: no registered projects. Projectless threads with the folder chosen per task work across restarts on every model. codex.exe in a terminal for anything that needs a project root.

Client logs and app-server log from the sessions above are available on request.

codex-hang-evidence-2026-09-18.zip

Codex_Desktop_Hang_Ticket_2026-09-18_v2.md

Codex_Handoff_2026-09-18.md

Start with the Windows desktop client send path and compare a working session with the hung client logs. Trace configRequirements/read through “turn-start config resolved” and turn/start, then inspect the corresponding app-server logs_2.sqlite entries. Done means prompt 2 sends and the composer returns to idle after turn/completed in registered projects.