[Windows][Codex Desktop 26.820.7780.0] GPT-5.6 Sol Ultra tool calls fail with "code-mode host exited during handshake", while GPT-5.5 works

I can reproduce this on the same environment:

• Codex Desktop 26.820.7780.0
• Bundled CLI 0.150.0-alpha.8
• Microsoft Windows NT 10.0.26200.0 x64
• ChatGPT Pro 5x

The same code-mode host exited during handshake error occurs before any local command runs, including in existing tasks, new tasks, and a new worktree. Restarting Codex Desktop and rebooting Windows did not help.

A manually started WebSocket code-mode host successfully completed a real exec tool call, while the normal Desktop stdio path still fails.

Additional reproduction:

Image generation also fails under GPT-5.6 with the same error:

code-mode host exited during handshake

The request fails before any image is generated. Text chat continues to work normally.

This suggests the issue affects non-shell tool calls as well, not only terminal commands.

I can reproduce the same regression on Windows with Codex Desktop 26.820.7780.0.

Observed behavior:

• GPT-5.6 Sol: every local tool/shell request fails before the command runs with code-mode host exited during handshake.
• The failure reproduces in existing tasks, forked tasks, and brand-new tasks, so it is not project-specific.
• Switching only the model to GPT-5.5 on the same machine, same desktop installation, same account, same PowerShell environment, and same working directory makes local execution work immediately.

Smoke test used after switching to GPT-5.5:

Write-Output 'CODE_MODE_SMOKE_OK'

Result: command actually executed, exit code 0, output CODE_MODE_SMOKE_OK.

Additional troubleshooting already performed before this A/B test:

• App repair/reinstall and multiple Windows restarts: no change.
• Package status reports OK and AppX registration was rebuilt.
• User runtime caches were rebuilt.
• CODEX_CLI_PATH was cleared.
• Defender/Application logs did not show a corresponding block/crash.
• A separately installed official npm Codex CLI works (codex-cli 0.149.1), but pointing Desktop at that CLI did not restore GPT-5.6 tool execution.

This strongly suggests a GPT-5.6 / Code Mode handshake regression in Desktop 26.820.7780.0 rather than a generic local execution, project path, or PowerShell problem.

I can reproduce this on another Windows machine with the same Desktop build, and I have one additional A/B result that may help narrow the failure path.

Environment:

• Codex Desktop: 26.820.7780.0
• Desktop bundled/cached CLI: codex-cli 0.150.0-alpha.8
• Desktop runtime path: %LOCALAPPDATA%\OpenAI\Codex\bin\d0097be4feba73d0\codex.exe
• Cached codex-code-mode-host.exe exists beside it, size 65880368 bytes
• Separately installed official CLI: codex-cli 0.149.1

Desktop behavior:

• GPT-5.6 Sol: local tool use fails with code-mode host exited during handshake
• GPT-5.5: local tool use works normally
• Restarting the Desktop app multiple times did not help
• The regression started immediately after updating the Desktop app today

Additional isolation:

1. Running the separately installed 0.149.1 CLI directly with GPT-5.6 successfully executes PowerShell tools.
2. More importantly, running the exact Desktop cached 0.150.0-alpha.8 binary directly also succeeds with GPT-5.6:

& "$env:LOCALAPPDATA\OpenAI\Codex\bin\d0097be4feba73d0\codex.exe" exec --skip-git-repo-check -m gpt-5.6-sol "Run pwd using the shell tool."

The command ultimately executed successfully and returned the working directory. The same cached CLI also successfully read local Skill files before executing pwd.

Other checks:

• CODEX_CODE_MODE_HOST_PATH is unset
• no duplicate codex.exe entries were found on PATH
• no matching Application Error / WER crash event was found for codex-code-mode-host.exe

This suggests the cached codex.exe + codex-code-mode-host.exe binaries themselves are functional with GPT-5.6 when invoked directly, while the failure is specific to the Desktop-integrated Code Mode startup/handshake path.

Confirmed: rolling back the complete Windows Desktop package fixes the
GPT-5.6 Code Mode handshake failure on the same machine.

Controlled version A/B:

Broken

Codex Desktop: 26.820.7780.0 x64
Bundled CLI: 0.150.0-alpha.8
Model: GPT-5.6 Sol Ultra
Result: code-mode host exited during handshake

The failure reproduced repeatedly before the first PowerShell command
was executed.

GPT-5.5 Extra High continued to execute local tools normally on the same
installation.

Working after rollback

I downloaded the official OpenAI CDN MSIX for:

OpenAI.Codex 26.818.8289.0 x64

I performed an in-place AppX downgrade with
-ForceUpdateFromAnyVersion. The resulting package state is:

Version: 26.818.8289.0
Architecture: X64
SignatureKind: Store
Status: Ok

CODEX_CLI_PATH remains unset at Process, User, and Machine scope.

After launching 26.818.8289.0, GPT-5.6 Sol successfully executed the
same PowerShell smoke test that failed on 26.820:

Write-Output 'CODE_MODE_SMOKE_OK'

Result:

Command actually executed
Exit code: 0
Output: CODE_MODE_SMOKE_OK

PowerShell 7 remains installed, and no AppX-volume, WindowsApps ACL,
ownership, Defender, PATH, or environment-variable changes were made
between the failing and working GPT-5.6 tests.

This strongly isolates the regression to the Desktop/runtime combination
introduced in 26.820.7780.0, rather than to PowerShell, the project,
the account, or a generally broken local tool environment.

I’m seeing the same issue on Windows Codex Desktop 26.820.7780.0. I added a detailed Windows repro with GPT-5.6 Sol + Luna failures, GPT-5.5 success, and GPT-5.6 CLI/app-server controls here: https://github.com/openai/codex/issues/32759#issuecomment-5424049843

Related Windows Desktop report with additional diagnostics: https://github.com/openai/codex/issues/40913

Key extra finding there: from the ChatGPT Desktop process context, spawning the bundled runtime fails at the lowest level:

C:\Users\c\AppData\Local\OpenAI\Codex\runtimes\cua_node\950613ca46815e82\bin\node.exe --version
nodeVersionError.code = 3221225506  (0xC0000022)

while the exact same node.exe launched manually from PowerShell succeeds (v24.19.0, exit 0). A full clean-room reset of all Codex/Desktop state, reinstall, disabling code_mode_host, Defender exclusions, and stopping Nahimic did not change the result. The main Desktop -> codex app-server stdio handshake succeeds; only the local code-mode execution child-chain fails. This points to the Desktop/MSIX packaged child-process context rather than the binaries or user state.

Additional evidence: the code-mode host is dying at the Windows loader level (0xC0000139), not failing the handshake protocol

Reproducing this on a second machine with an even newer build, and I can add three pieces of evidence that narrow the root cause considerably.

Environment: Codex Desktop 26.820.9563.0 (Store, newer than the reporter's 26.820.7780.0 — still broken), bundled CLI 0.150.0-alpha.8, Windows 11 10.0.26200, Pro plan. Same symptom: every local tool call under GPT-5.6 (Sol and Terra) returns code-mode host exited during handshake; GPT-5.5 in the same Desktop build works.

1. A second V8 victim has been dying with a loader NTSTATUS for days

The Desktop app's own browser-use runtime probe logs this in every session since at least 2026-08-24 (found in %LOCALAPPDATA%\Packages\OpenAI.Codex_<pfm>\LocalCache\Local\Codex\Logs\<date>\codex-desktop-*.log):

[BrowserUseThreadConfig] browser_use_runtime_paths_selected ...
nodeVersionError={"code":3221225506,"killed":false,"signal":null,
  "cmd":"C:\\...\\AppData\\Local\\OpenAI\\Codex\\runtimes\\cua_node\\<hash>\\bin\\node.exe --version",
  "stdout":"","stderr":""}
nodeVersionStatus=failed

3221225506 = 0xC0000139 STATUS_ENTRYPOINT_NOT_FOUND — a Windows loader error. The identical node.exe --version from a terminal prints v24.19.0 and exits 0. So V8-family executables spawned inside the Desktop process tree have been dying at image-load time for a while; GPT-5.6's code-mode host is just the newest victim. This also reproduces across two different cua_node runtime hashes and two app builds on my machine.

2. Under RUST_LOG=debug, the host emits zero stderr before dying

The app passes its own RUST_LOG through to the app-server: the bundle contains RUST_LOG: process.env.RUST_LOG ?? 'warn'. Launching the Desktop app from a shell with RUST_LOG=debug therefore enables debug logging in the GUI's app-server, and its logs land in ~/.codex/logs_2.sqlite.

Result during three consecutive code-mode host exited during handshake failures (confirmed rows in logs_2.sqlite, target=codex_core::tools::router, otel.name=exec, model=gpt-5.6-sol):

• zero code-mode host stderr: ... lines (the stderr pump in codex-rs/code-mode/src/remote_session/connection.rs logs every host stderr line at debug)
• no process with the host image visible to a 150 ms process-creation poller

Conclusion: the host process is created and dies before its Rust runtime prints anything — i.e. it dies in the loader, matching the 0xC0000139 signature above, and the error string surfaces as "exited during handshake" only because stdout hits EOF.

3. Everything machine-specific has been ruled out

• Environment/PATH: dumped the exact PEB environment of both the Electron main process and the GUI's app-server and re-ran node.exe --version and codex-code-mode-host.exe under those environments from an external process — all pass (even with PATH/SystemRoot removed entirely).
• Sandbox: fails identically under danger-full-access; codex sandbox -- <bundled node.exe> --version works.
• Binary integrity: the per-user bin-cache copy and the MSIX app\resources\codex-code-mode-host.exe copy are byte-identical (same SHA-256), and InstallContext::code_mode_host_program() prefers the resources copy — so both spawn candidates are the same, healthy file. codex exec --model gpt-5.6-sol "run Write-Output ..." from a terminal completes a full code-mode tool call.
• DLL shadowing: the package ships dbghelp.dll/dbgcore.dll (10.0.26100.7705 vs system 10.0.26100.8328), but both export tables are identical (252 exports each); node imports only MiniDumpWriteDump and the host only StackWalk64 from dbghelp, present in both. Placing the packaged dbghelp next to node.exe does not break it.
• No WER/Application-event entries; no third-party DLL injectors; previously-cleaned sandbox DENY ACEs unrelated (failure persists with them removed).

What correlates instead: inside the packaged Desktop process tree, only V8/Node-family executables die (bundled node.exe, codex-code-mode-host.exe); everything else spawned by the same tree survives — the Rust app-server codex.exe, codex-command-runner.exe, pwsh, rg, python. Notably the two victims are also the only processes whose static imports include WINMM.dll/dbghelp.dll. The same binaries run fine when spawned from a terminal or via codex sandbox. A local shim is not possible: the app verifies and reverts modifications under %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\ and runtimes\cua_node\ at startup.

Workaround

• Desktop: use GPT-5.5 (or any non-5.6 model).
• GPT-5.6: works fully via CLI (codex --model gpt-5.6-sol), including code-mode tool calls.

Cross-referencing #32759 — the model-specific handshake death on another platform suggests whatever changed server/client-side for 5.6 code mode, on Windows it manifests as a loader-level death of the host binary when spawned from the packaged app. It would help if the spawn error surfaced the child exit status (the current error string drops it) — that single number would have made this unambiguous immediately.

Yes, I’m running into this issue too; I can't use the 5.6 model and am forced to use 5.5 instead. When will this be fixed? I haven't been able to use 5.6 for two days now.

I can reproduce the same model-specific Code Mode failure on Windows Codex Desktop.

Summary

GPT-5.6 fails before any local tool/file operation is executed with:

code-mode host exited during handshake

Switching only the model to GPT-5.5 immediately restores local file/tool execution in the same environment.

Minimal reproduction

1. Open Codex Desktop on Windows.
2. Start a local task using GPT-5.6.
3. Ask it to create a simple file:

Create test.txt with content hello

1. The file is not created. The task reports:

code-mode host exited during handshake

1. Switch the same task/environment to GPT-5.5.
2. Run the same request again.
3. The file operation works normally.

Notes

This does not appear to be a Word, Python, python-docx, filesystem permission, or workspace-specific issue, because even creating a plain test.txt fails under GPT-5.6 and works after switching to GPT-5.5.

I do not have the exact Codex Desktop version available in this comment, but the A/B result is consistent and reproducible:

• GPT-5.6: local Code Mode fails during handshake
• GPT-5.5: local file/tool execution works

https://github.com/openai/codex/issues/41049#issuecomment-5438015120 downgrade works for me

5.5确实没啥问题，但是我要用5.6啊。我买都买了。肯定要5.6.另外你用7月份的beta版本可以使用5.6，当前我试过了，是可以的