Windows Codex Desktop GPT-5.6 fails with "code-mode host exited during handshake" while GPT-5.5 Desktop and GPT-5.6 CLI work

Open 💬 5 comments Opened Aug 26, 2026 by noa94189-cell
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.820.7780.0

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop consistently fails to execute local tools with GPT-5.6 on my Windows PC.

The exact error is:

code-mode host exited dur

Codex_GPT56_Bug_Evidence_Package.zip

ing handshake

Commands such as whoami never actually execute, and Desktop returns:

stdout: unavailable
exit code: unavailable

Important A/B result:

GPT-5.5 Desktop: WORKS
GPT-5.6 Desktop: FAILS
GPT-5.6 Luna CLI: WORKS
GPT-5.6 Sol CLI: WORKS

A second Windows PC using the same ChatGPT/Codex account, the same Windows build, the same Codex Desktop version, the same Codex CLI version, and the same codex.exe SHA256 can execute GPT-5.6 tools normally in Codex Desktop.

The affected machine has been tested with both the standalone and npm Codex 0.149.1 layouts. Codex Desktop was verified to actually use the npm vendor codex.exe, but GPT-5.6 Desktop still fails.

The WebSocket connection has also been verified successfully with HTTP 101 Switching Protocols. The Skills traversal issue was separately isolated. codex-code-mode-host.exe exists, has a valid OpenAI signature, valid ACLs, and can be executed manually with --help, returning exit code 0.

The failure appears specific to the Codex Desktop -> GPT-5.6 -> Code Mode Host handshake path.

Codex_GPT56_Bug_Evidence_Package.zip

Codex_bug_reproduction_steps.txt

What steps can reproduce the bug?

Feedback ID: 01a03f09-6f13-7f30-a8c6-15c9254048b9

What is the expected behavior?

GPT-5.6 in Codex Desktop should start the local tool, execute whoami, and return the real stdout and exit code.

The expected behavior is the same as GPT-5.5 Desktop and GPT-5.6 CLI on the affected machine.

For example:

stdout: <actual Windows/Codex sandbox identity>
exit code: 0

Additional information

Affected machine:

  • Windows 11 Home, Build 26200, x64
  • Codex Desktop: 26.820.7780.0
  • codex-cli: 0.149.1
  • codex.exe SHA256:

A395030B56B126F608F2403036DDDB654A9C063213E9C2B5F85D954CF490EBE6

Working comparison machine:

  • Same ChatGPT/Codex account
  • Windows 11 Home, Build 26200, x64
  • Codex Desktop: 26.820.7780.0
  • codex-cli: 0.149.1
  • Same codex.exe SHA256
  • GPT-5.6 Desktop tool execution works normally

Additional diagnostics already performed:

  • Desktop -> codex app-server stdio initialization succeeds.
  • Both gpt-5.6-luna and gpt-5.6-sol execute real shell commands successfully through CLI.
  • GPT-5.5 Desktop works on the affected PC.
  • Reproduced in a new conversation and normal local workspace.
  • Tested both standalone and npm Codex 0.149.1 layouts.
  • Verified Desktop is actually launching the npm vendor codex.exe with features.code_mode_host=true.
  • Codex Doctor reports installation consistent.
  • WebSocket handshake succeeds with HTTP 101 Switching Protocols.
  • Large .codex/skills tree was isolated and reduced; failure remains.
  • codex-code-mode-host.exe has a valid OpenAI Authenticode signature.
  • ACLs permit execution.
  • codex-code-mode-host.exe --help runs normally and exits with code 0.
  • Process monitoring did not capture a normal Code Mode Host lifecycle during the Desktop GPT-5.6 failure.
  • Similar bundled executable relocation warnings are also present on the working comparison PC.

Suspected failing layer:

Codex Desktop
-> codex.exe app-server
-> successful app-server initialization
-> GPT-5.6 tool request
-> Code Mode Host initialization
-> Desktop / Code Mode Host handshake

Codex_bug_reproduction_steps.txt

-> code-mode host exited during handshake

Please investigate the Windows GPT-5.6 Desktop Code Mode Host spawn/handshake path, including host process creation, inherited environment, stdio/pipe handles, host stderr and exit status, and differences between GPT-5.5 and GPT-5.6 tool dispatch.

Codex_GPT56_Bug_Evidence_Package.zip

Codex_bug_reproduction_steps.txt

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 day ago

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

  • #40798
  • #40913
  • #40899

Powered by Codex Action

noa94189-cell · 1 day ago

Additional Codex Desktop feedback was submitted immediately after reproducing the GPT-5.6 failure.

Feedback ID: 01a03f09-6f13-7f30-a8c6-15c9254048b9

The failure reproduced as:

GPT-5.6 Desktop → code-mode host exited during handshake
GPT-5.5 Desktop → works
GPT-5.6 CLI on the same machine/account → works

This feedback was submitted from the affected Windows machine so the internal diagnostics can hopefully be correlated with Issue #40943.

wangzongshuji · 1 day ago

Is it solved? The 5.5 model doesn't have this problem, but the 5.6 model doesn't work either

keros68 · 1 day ago

I can reproduce a closely matching Desktop-only variant on another Windows machine.

Environment:

  • Windows Codex Desktop: 26.820.9563.0
  • Codex CLI: 0.149.1
  • Shell: PowerShell on Windows
  • Desktop permission mode tested: workspace-write

Reproduction prompt used in Desktop GPT-5.6:

Run Get-Date using the shell tool. Do not answer without executing.

Actual Desktop GPT-5.6 result:

code-mode host exited during handshake

The command never reaches PowerShell.

A/B results on the same machine/account/workspace:

  • Desktop + GPT-5.6: fails before command execution with code-mode host exited during handshake.
  • Desktop + GPT-5.5: succeeds and can execute Get-Date.
  • CLI + gpt-5.6-luna: succeeds and can execute the same shell test.
  • CLI + gpt-5.6-terra: succeeds and can execute the same shell test.
  • CLI + gpt-5.5: succeeds.

Local read-only checks:

  • Desktop app-server initialization logs show successful stdio initialization.
  • The code-mode host executable exists in the active Desktop Codex install/runtime locations.
  • Bundled Node and Python runtimes execute normally.
  • Windows Application Event Log and Defender detections did not show a matching Codex/code-mode-host crash or block during the checked window.

This seems narrower than a general GPT-5.6, account, CLI, PowerShell, Node/Python, or sandbox failure. The suspected failing layer is Desktop GPT-5.6 tool dispatch -> local Code Mode host spawn/handshake.

noa94189-cell · 15 hours ago

Update: I found a reproducible workaround, and it strongly points to a Windows Desktop regression in the 26.820 build line.

Failing configuration

  • Windows Codex Desktop: 26.820.9563.0
  • GPT-5.6 Desktop: fails on the first local tool/shell call with code-mode host exited during handshake
  • GPT-5.5 Desktop: works
  • GPT-5.6 CLI on the same machine/account: works
  • Clean reinstall of Codex Desktop did not fix the GPT-5.6 Desktop failure

Workaround that fixed it

I downgraded the Windows Desktop package from:

26.820.9563.0

to:

26.818.8289.0

(the codex-app-26.818.61809 Desktop release / Windows x64 MSIX).

I kept the same Windows installation, account, network, projects, and .codex data. CODEX_CLI_PATH was blank at Process/User/Machine scope after the downgrade, and the Desktop app launched its own bundled codex.exe from:

C:\Program Files\WindowsApps\OpenAI.Codex_26.818.8289.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

After the downgrade, GPT-5.6 Desktop immediately started executing local commands successfully.

Verification

whoami:

stdout: ...\codexsandboxoffline
stderr: <empty>
exit code: 0

cmd /c echo CODEX_56_TEST_OK:

stdout: CODEX_56_TEST_OK
stderr: <empty>
exit code: 0

So the A/B result on the same machine is:

26.820.9563.0 + GPT-5.6 Desktop -> handshake failure
26.818.8289.0 + GPT-5.6 Desktop -> local execution works

This makes the issue look much more like a regression in the newer Windows Desktop/runtime/tool-dispatch path than a general GPT-5.6, PowerShell, account, network, Defender, or CLI problem.

This also appears consistent with the Desktop-only reports in #32759.

Note: for my downgrade test I used the 26.818.8289.0 x64 MSIX from the community mirror Wangnov/codex-app-mirror; I verified that the downloaded file matched the published SHA256 and that Windows reported a valid Authenticode signature before installing it. I am reporting this as a workaround / A-B diagnostic result, not as an official recommended distribution path.