GPT-5.6 Sol local tools fail in Codex Desktop on Windows: code-mode host exited during handshake
Summary
On Windows x64, local tool execution in Codex Desktop fails reproducibly with GPT-5.6 Sol during the code-mode host handshake. The same simple local command succeeds in the same app/environment after switching the task to GPT-5.5.
Observed error:
code-mode host exited during handshake
This looks like a GPT-5.6-specific Codex Desktop / code-mode host tool-negotiation issue, not a general shell, filesystem, sandbox, model-availability, or MFA/authentication issue.
Environment
- OS: Windows x64 / AMD64
- Codex Desktop package observed:
OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0 - Bundled Codex runtime observed:
codex-cli 0.150.0-alpha.8 - Also tested runtime:
codex-cli 0.149.0 - Failing models:
gpt-5.6-sol,gpt-5.6-luna - Working model:
gpt-5.5
Expected behavior
GPT-5.6 Sol should be able to use local Codex tools in Codex Desktop on Windows x64, or fall back to the same working local command execution path used by GPT-5.5. A simple directory listing should not fail before the command actually runs.
Actual behavior
When GPT-5.6 Sol attempts to run a simple local command, the tool call fails before command execution with:
code-mode host exited during handshake
Switching the same task/environment to GPT-5.5 allows the local command to run successfully and list the expected directories.
Reproduction outline
- Open Codex Desktop on Windows x64.
- Start a local task using
gpt-5.6-sol. - Ask Codex to run a simple local command, such as listing the current directory.
- The tool call fails with
code-mode host exited during handshake. - Switch the task to
gpt-5.5. - Run the same type of local directory-listing command.
- The command succeeds.
A/B evidence from local session logs
I have multiple local session logs showing the same pattern:
- With
gpt-5.6-sol:comp_hash=3000,multi_agent_version=v2, local tool call fails withcode-mode host exited during handshake. - With
gpt-5.6-luna: same handshake failure. - With
gpt-5.5:comp_hash=2911, local command execution succeeds.
I can provide the session JSONL files privately if useful. I am not attaching them publicly because they contain local transcript details.
Local model catalog observations
The local model cache shows a relevant routing difference:
gpt-5.6-sol:
{
"use_responses_lite": true,
"tool_mode": "code_mode_only",
"multi_agent_version": "v2",
"comp_hash": "3000",
"max_context_window": 872000
}
gpt-5.5:
{
"use_responses_lite": false,
"tool_mode": "<absent>",
"multi_agent_version": "<absent>",
"comp_hash": "2911",
"max_context_window": 272000
}
Temporarily changing the local cache fields for GPT-5.6 entries did not produce a durable fix; fresh GPT-5.6 tasks still showed comp_hash=3000 and failed. This suggests the effective GPT-5.6 tool route is not controlled solely by models_cache.json, or it is refreshed/overridden by the app/backend.
Mitigation attempts already tested
- Switching from GPT-5.6 Sol to GPT-5.5: local command execution works.
- Testing GPT-5.6 Luna: same handshake failure.
- Temporarily patching local model-cache routing fields for GPT-5.6: no durable fix.
- Testing Codex runtime
0.149.0instead of0.150.0-alpha.8: GPT-5.6 Sol still fails with the same handshake error. - Checking sandbox setup logs: setup completed with
errors=[]. - Checking for MFA / 403-style failures in the relevant logs: no
403 Forbidden,Multi-factor authentication required, ormfa_requiredevidence was found. - Manually starting
codex-code-mode-host.exe --listen ws://127.0.0.1:0: the host can start/listen manually, so the binary does not appear to be simply missing or unable to launch.
Request
Could the Codex team check whether the GPT-5.6 Sol/Terra/Luna tool route currently has a compatibility issue with Codex Desktop's Windows code-mode host handshake, especially around:
tool_mode=code_mode_onlyuse_responses_lite=truemulti_agent_version=v2comp_hash=3000- Desktop runtime
0.150.0-alpha.8and0.149.0on Windows x64 - the transition from GPT-5.5-style local shell execution to the GPT-5.6 code-mode host execution path
1 Comment
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action