GPT-5.6 Sol 在 Windows 上突然“终端启动握手失败”：一次 code-mode host exited during handshake 排障实录
2026 年 8 月底，一批 Windows 用户发现：Codex 能正常对话，却无法读取项目、修改文件或执行命令。只要切回 GPT-5.5，一切又立即恢复。问题最终指向了哪里？社区找到的解决办法是否可信？
一个很容易误判的故障
最初的现象并不复杂。
在 Windows 版 Codex 中选择 GPT-5.6 Sol，让它读取当前目录或执行一条简单命令，任务会在真正运行命令之前失败，界面显示：
code-mode host exited during handshake这句话可以直译为：负责代码模式的本地主机，在初始化握手期间退出了。
它容易让人沿着错误方向排查：是不是项目坏了？是不是中文路径有问题？是不是 PowerShell、Git 或文件权限异常？但 openai/codex#41049 中逐渐积累的复现信息，基本排除了这些猜测。
多位用户在同一台电脑、同一个项目和同一套 Codex 安装中做了 A/B 测试：
| 条件 | 结果 |
|---|---|
GPT-5.5 执行 Get-Date、读取文件 |
正常 |
| GPT-5.6 Sol 执行相同操作 | 握手阶段失败 |
| GPT-5.6 Terra / Luna 执行相同操作 | 也有用户复现失败 |
| 在 Codex 外运行 PowerShell、CMD、Git | 正常 |
| 更换项目或新建任务 | 仍可能失败 |
| 重启、重装、重建 sandbox | 对部分用户无效 |
关键点在于：失败发生在 PowerShell 或文件解析器启动之前。 所以无论当时的任务是读取代码、处理 Word/PDF，还是安装 Skill，最终都可能表现为同一个错误。问题不是某个文件不能读，而是承载本地工具调用的进程根本没有完成启动。
为什么 GPT-5.5 正常，GPT-5.6 却失败
讨论中最有价值的一条诊断，来自一位用户对本地会话记录的对比。
GPT-5.5 的调用路径是：
function_call
-> exec_command
-> unified_exec
-> pwsh.exe
-> successGPT-5.6 的调用路径则是：
custom_tool_call
-> exec / code-mode
-> codex-code-mode-host.exe
-> handshake failure这解释了一个看似矛盾的现象：聊天和推理仍然正常，但模型一旦需要“动手”，便立刻失败。
从用户提供的 models_cache.json 看，GPT-5.6 Sol、Terra 和 Luna 当时都标记为 code_mode_only，会进入 codex-code-mode-host.exe 这条执行路径；GPT-5.5 则仍能通过另一条本地执行路径完成命令。这个差异能够解释 A/B 结果，但不能单独证明根因一定在模型本身。更准确地说，这是 GPT-5.6 所使用的本地执行路径与特定 Windows 环境之间的兼容性问题。
转折点：SafeDllSearchMode
真正让讨论从“集体复现”走向“可操作方案”的，是一项 Windows 注册表设置：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
SafeDllSearchMode一位用户发现，该值在自己的电脑上被明确设置为 0。将它改为 1 并完整重启 Windows 后，codex-code-mode-host.exe 能够正常启动，本地命令、已安装 Skill、外部数据调用和搜索也恢复了。之后又有多位用户报告了相同的前后对比结果，包括 Word/PDF 读写恢复。
这条线索并非毫无依据。根据微软的 Dynamic-link library search order 文档：
- 安全 DLL 搜索模式默认启用；
SafeDllSearchMode=0会关闭它；- 启用后，Windows 会把当前工作目录放到 DLL 搜索顺序中更靠后的位置；
- 这样更有机会先找到应用目录或系统目录中的合法 DLL。
微软在 Dynamic-Link Library Security 中还明确建议，在使用标准 DLL 搜索顺序时保持安全搜索模式开启，以降低 DLL 预加载或 binary planting 攻击的风险。
于是，一个合理但仍待官方确认的解释出现了：codex-code-mode-host.exe 启动时需要加载 DLL；在部分机器上，关闭的安全 DLL 搜索模式改变了查找顺序，导致它加载到错误或不兼容的 DLL，随后在握手完成前退出。
请注意，这仍是基于社区复现的推断。截至 2026 年 8 月 31 日，该 issue 仍处于 open 状态，讨论中没有 OpenAI 维护者公布正式根因，也没有官方确认 SafeDllSearchMode=0 能解释所有案例。
建议的处理顺序
如果你遇到完全相同的错误，建议按风险从低到高处理。
1. 先切换到 GPT-5.5
这是讨论中验证最充分、风险最低的临时方案。它不会修复 GPT-5.6 的 code-mode 路径，但能立即恢复本地命令和文件操作，避免工作被阻塞。
2. 只读检查注册表值
在 PowerShell 或命令提示符中执行：
reg.exe query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v SafeDllSearchMode如果返回 0x1，说明安全 DLL 搜索模式已经启用，不要反复修改。你的问题可能属于同一症状下的另一类原因，应继续收集日志并等待官方修复。
如果返回 0x0，这与 issue 中多位成功恢复用户的环境一致。先记录原值，再考虑下一步。
3. 仅在值为 0 时改为 1
以管理员身份打开 PowerShell，执行：
reg.exe add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v SafeDllSearchMode /t REG_DWORD /d 1 /f再次查询确认结果：
reg.exe query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v SafeDllSearchMode然后完整重启 Windows，仅退出并重开 Codex 可能不够。
重启后，用最小任务验证：
请运行 Get-Date 和 Get-Location，并列出当前目录中的文件。如果这些命令能够执行，再测试真实项目中的读写操作。
哪些方案不适合作为首选
讨论中还出现过两个临时方向：回滚 Codex 客户端，以及复制 Codex CLI 和辅助程序、再通过自定义 shim 改变工作目录。
它们为定位问题提供了有价值的线索，但不适合普通用户优先尝试：
- 从第三方镜像下载旧安装包存在供应链风险，且版本可能很快自动更新；
- 自定义 shim 需要处理 MSIX/WindowsApps 权限、复制多个版本绑定的可执行文件并设置
CODEX_CLI_PATH，升级后还可能失效； - 如果操作不完整，可能进一步引入
Access is denied、辅助程序缺失或 app-server 无法启动等问题。
除非你正在协助官方做最小复现，并且能够校验文件哈希、理解脚本和完整回滚，否则不建议把这些方案当成常规修复。
这次排障真正值得记住的三件事
第一，“模型能回答”不等于“本地执行环境正常”。现代编码 Agent 至少包含模型推理、工具路由、本地主机、shell 与 sandbox 等多层。握手失败时，项目代码甚至还没有被触碰。
第二，同机 A/B 测试比重装更有诊断价值。同一项目下 GPT-5.5 成功、GPT-5.6 失败，迅速把范围从项目文件、路径和 shell 收敛到了两者不同的工具执行路径。
第三，有效的社区 workaround 也不等于已确认的根因。SafeDllSearchMode=1 有明确的微软安全文档支撑，也已有多例恢复反馈，但仍需要 OpenAI 解释 code-mode host 具体加载了什么、为何只在某些 Windows 环境中退出，以及客户端是否应该提供更明确的错误日志或启动保护。
结语
code-mode host exited during handshake 最令人困惑的地方，是它让 Codex 看起来“还活着”：模型可以分析问题，却无法读取目录、修改文件或运行最简单的命令。
这场讨论把问题逐步拆开了：不是中文路径，不是某个 DOCX，不是 PowerShell 本身，也不太像单纯的订阅差异；真正失败的是 GPT-5.6 所依赖的 code-mode 本地主机启动链路。SafeDllSearchMode 为部分 Windows 用户提供了一个有安全依据、且被多次验证的恢复方法，但在官方给出结论之前，它仍应被称为临时解决方案，而不是最终修复。
参考资料
- GitHub Issue：openai/codex#41049
- 详细的 GPT-5.5 / GPT-5.6 调用路径对比
SafeDllSearchMode的首次完整前后对比- Word/PDF 操作恢复的社区验证
- 微软：Dynamic-link library search order
- 微软：Dynamic-Link Library Security
状态说明：本文基于该 issue 截至 2026 年 8 月 31 日的公开内容整理。后续客户端版本、官方结论或修复状态可能发生变化。
Comments