code-mode host exited during handshake; the 5.6 model is not working properly

English translation:

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

Version 26.820.71523

What subscription do you have?

pro 20x

What platform is your computer?

win10 H22

What issue are you seeing?

The directory could not be read automatically just now because the local command execution channel exited unexpectedly during the initialization handshake (code-mode host exited during handshake). It was not caused by corrupted project files or a Chinese path. The 5.6 model is not working properly, so I can only use 5.5 now.

What steps can reproduce the bug?

Feedback ID: 01a0418f-d5fa-7d72-bb4a-c67e8bb31044

What is the expected behavior?

_No response_

Additional information

_No response_

<!-- codex-issue-translator -->

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

• #40944
• #40943
• #40798
• #41034
• #40899

Powered by Codex Action

我也遇到了，重装chatgpt，重启电脑都不行，这个能降版本吗？

我也遇到了，有解决么

遇到+1

I’m experiencing the same issue. Has anyone found a solution or workaround for this?

遇到了+1，无法读写文件，并且显示原始信息为：
code-mode host exited during handshake

Has the same problem not been solved yet?

Has the same problem not been solved yet?

+1

你是怎么解决的呢

我也遇到了，目前有什么办法解决吗

我也不知道怎么解决你有办法吗

我也不知道怎么解决你有办法吗

<img width="1655" height="956" alt="Image" src="https://github.com/user-attachments/assets/753036d9-9d4e-43c8-9970-254ee762c381" /> 要不要回滚版本到26.818.8289.0？

没有安装包怎么回滚呢

没有安装包怎么回滚呢

确实。 我很奇怪，我昨天从plus升级到pro，然后就不能用了；之前用的plus，没记得有这个问题。我今天捣鼓了一下午，发现5.6的三个模型都不行，但是5.5 5.4 模型都能用， code_mode_host这个能关闭吗？

感觉就是pro的问题 好烦躁

感觉就是pro的问题 好烦躁

是不是也是刚升级到pro后，才出现的这个问题？

不是

https://github.com/Wangnov/codex-app-mirror/releases#release-codex-app-26.818.61809
You can download the package here and test if it works.

先给你说个结论。我跟我老婆同一个pro账号，我验证了下她的电脑用5.6sol就可以读取，操作，不需要握手；我的就不可以。https://github.com/openai/codex/issues/32759 这个帖子你可以参考系下。后来我就让5.6sol给我找问题，然后再powershell中进行输入代码，最终就跳过握手，解决了这个问题

<img width="1674" height="870" alt="Image" src="https://github.com/user-attachments/assets/eb4705f7-93c1-43ae-9b1f-7cee76dedb4f" />

<img width="1660" height="663" alt="Image" src="https://github.com/user-attachments/assets/dd3766a9-6df3-4ee4-93ae-a65910dd9b10" />

<img width="1587" height="1245" alt="Image" src="https://github.com/user-attachments/assets/40c17925-70b2-442e-8474-47617cf99c16" />

具体是怎么操作的

https://github.com/Wangnov/codex-app-mirror/releases#release-codex-app-26.818.61809 You can download the package here and test if it works.

Awesome, this works for me, thank you so much

I’m experiencing the same issue on Windows after the recent Codex update, and I want to add another reproducible case.

Symptoms:

• With GPT-5.6 selected, Codex is unable to execute local commands / tool calls reliably. It may sit without doing the requested work or fail to start local execution.
• Switching the same chat/project to GPT-5.5 restores command execution and Codex starts working again.
• Codex itself now takes a very long time to start after the update.
• Existing/new chats can take a long time to load and sometimes appear to hang or remain unresponsive.
• This behavior appeared after the recent Windows Codex update; the project itself was working before.

This looks related to the 5.6 local-execution/handshake regression reported in this issue, and possibly also to the Windows 26.820 local execution/startup regression tracked in #41088.

Please prioritize investigation of the Windows + GPT-5.6 path. GPT-5.5 is currently the only usable workaround for me, but the application startup/chat-loading slowdown is also present.

Expected behavior:

• GPT-5.6 should execute the same local commands that GPT-5.5 can execute on the same machine/project.
• Codex should start normally and chats should load without long hangs.

If useful, please indicate which logs/diagnostics would best help distinguish the GPT-5.6 tool-call failure from the broader Windows 26.820 startup/chat-loading regression.

I am experiencing the same issue on Codex Desktop for Windows.

Environment

• Codex Desktop version: 26.820.71523
• Operating system: Windows 11 Home Chinese Edition
• Windows version: 10.0.26200, build 26200
• Architecture: x64
• Subscription: ChatGPT Plus
• Affected model: GPT-5.6
• Working model for comparison: GPT-5.5

Error

The local command execution environment fails during the startup handshake. Codex retries three times and then stops.

The error shown in the UI is approximately:

The current command execution environment failed three consecutive times during the startup handshake.

The underlying error is:

code-mode host exited during handshake

Reproduction steps

1. Open Codex Desktop on Windows.
2. Create a new task in any local project.
3. Select GPT-5.6.
4. Ask Codex to run a simple command, for example:

List the files in the current directory.

1. The command environment fails during the startup handshake.
2. Codex retries three times and then stops without executing the command.

Troubleshooting already attempted

• Created a completely new task.
• Tested multiple local projects.
• Tested a simple command in a local directory.
• Rebuilt the Windows Codex sandbox successfully using:

codex sandbox setup --elevated --current-user

• Restarted Codex Desktop.
• Restarted Windows.
• The issue still occurs.
• The failure happens before the actual shell command is executed.
• It does not appear to be caused by the project files or an old task cache.

Expected behavior

Codex should start the local command execution host, complete the handshake, and execute the requested command.

Actual behavior

The code-mode host exits during the handshake. Codex retries three times and then reports that the command execution environment could not start.

Additional observation

GPT-5.5 works correctly in the same projects and on the same computer.

The issue started suddenly on August 27, 2026, and it reproduces in every project I tested. Codex Desktop itself opens normally.

I can provide sanitized logs or a Feedback ID if needed.

I encountered the exact same error on Windows:

code-mode host exited during handshake

The impact was broader than directory access or a single tool call. While the issue was present:

• Minimal local commands such as Get-Date and Get-Location failed before execution.
• Web/finance requests failed before being dispatched.
• Asking Codex to install skills from GitHub also failed.
• The built-in skill-installer could not even read its own installation instructions or start the GitHub download script.
• Reading an already-installed skill's SKILL.md failed with the same handshake error.
• Restarting only the Codex app did not resolve the problem.
• The same failure occurred in another Codex task, so it was not limited to one project or working directory.

Examples of GitHub skill repositories that could not be installed or accessed through Codex at that time included:

• https://github.com/quantskills/quantskills
• https://github.com/deluo/fund-dca-skill
• https://github.com/Garyjie/neodata-financial-search

The GitHub requests did not appear to start. The failure occurred earlier, while the local code-mode host was starting.

I found this Windows registry value explicitly set to 0:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager
SafeDllSearchMode    REG_DWORD    0x0

I changed it from an elevated terminal:
`reg.exe add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v SafeDllSearchMode /t REG_DWORD /d 1 /f` 



After verifying that it was 0x1 and performing a full Windows restart:
- Local commands executed normally.
- codex-code-mode-host.exe started successfully.
- Installed skill files could be read again.
- External financial-data skill calls and web searches worked again.
Environment:
- Windows version: 25H2
- Windows build: 26200.9168
- Codex App version: [paste version from “About Codex”]
This is one-machine evidence, not proof that SafeDllSearchMode=0 causes every occurrence. However, the before/after behavior was clear and suggests investigating Windows DLL search order during codex-code-mode-host.exe startup.

I can consistently reproduce the same issue in Codex Desktop.

A/B test in the same client, on the same machine and workspace, using a very simple file task ("create a .txt file"):

• GPT-5.5: works normally
• GPT-5.6 Luna: fails
• GPT-5.6 Terra: fails
• GPT-5.6 Sol: fails

For GPT-5.6 Sol, the UI reports:
code-mode host exited during handshake

I also cannot reliably read/write workspace files with the 5.6 variants, including TXT, Word, and PDF-related tasks.

I already updated Codex, restarted the app multiple times, terminated background processes, and retried. The behavior remains unchanged. Since GPT-5.5 succeeds immediately under the same conditions, this looks specific to the GPT-5.6 tool/workspace runtime rather than a local file-permission or document-format issue.

Hope this A/B result helps narrow down the regression.

下面是一份可直接粘贴到 [GitHub issue #32759](https://github.com/openai/codex/issues/32759) 的英文说明。它总结了我们实际遇到的全部错误、最终生效的代码和回滚方式。

---

WindowsApps variant: copy the bundled CLI and helper executables before using the CWD shim

I confirmed the CWD-related workaround, but on my Microsoft Store/MSIX installation the original approach needed one additional step.

Tested environment

• Codex Desktop: 26.820.9563.0
• Bundled CLI: codex-cli 0.150.0-alpha.8
• Installation type: Microsoft Store/MSIX under C:\Program Files\WindowsApps
• Initial error: code-mode host exited during handshake

Additional problem

Launching the bundled CLI directly from an unpackaged PowerShell process failed:

Program "codex.exe" failed to run: Access is denied.
Exit code: 5

A shim pointing directly to:

C:\Program Files\WindowsApps\...\app\resources\codex.exe

also caused Codex Desktop to fail during startup:

ChatGPT failed to start
code=5
Codex app-server websocket closed

The working solution was:

1. Copy the official bundled codex.exe outside WindowsApps.
2. Copy its three sibling helper executables.
3. Compile a forwarding shim that:

• changes CWD to %USERPROFILE%;
• points the child CODEX_CLI_PATH to the copied CLI;
• forwards the original raw command-line arguments;
• directly inherits stdin/stdout/stderr handles.

1. Set the user-level CODEX_CLI_PATH to the shim.
2. Restart Codex Desktop.

Installation script

Completely quit Codex Desktop first, then run this in a fresh Windows PowerShell session:

$ErrorActionPreference = "Stop"

# Locate the current MSIX installation.
$pkg = Get-AppxPackage -Name OpenAI.Codex |
    Sort-Object Version -Descending |
    Select-Object -First 1

if (-not $pkg) {
    throw "OpenAI.Codex MSIX package was not found."
}

$sourceDir = Join-Path `
    -Path $pkg.InstallLocation `
    -ChildPath "app\resources"

$binDir = Join-Path $env:USERPROFILE ".codex\bin"

New-Item -ItemType Directory -Path $binDir -Force |
    Out-Null

# Copy the CLI outside WindowsApps so an unpackaged shim can execute it.
$sourceCodex = Join-Path $sourceDir "codex.exe"
$copiedCodex = Join-Path `
    $binDir `
    ("codex-real-{0}.exe" -f $pkg.Version)

$helperNames = @(
    "codex-code-mode-host.exe",
    "codex-command-runner.exe",
    "codex-windows-sandbox-setup.exe"
)

$requiredFiles = @("codex.exe") + $helperNames

foreach ($name in $requiredFiles) {
    $sourceFile = Join-Path $sourceDir $name

    if (-not (Test-Path -LiteralPath $sourceFile)) {
        throw "Required bundled file was not found: $sourceFile"
    }
}

Copy-Item `
    -LiteralPath $sourceCodex `
    -Destination $copiedCodex `
    -Force

foreach ($name in $helperNames) {
    Copy-Item `
        -LiteralPath (Join-Path $sourceDir $name) `
        -Destination (Join-Path $binDir $name) `
        -Force
}

# Verify that the copied CLI is byte-identical to the bundled CLI.
$sourceHash = (Get-FileHash -LiteralPath $sourceCodex -Algorithm SHA256).Hash
$copiedHash = (Get-FileHash -LiteralPath $copiedCodex -Algorithm SHA256).Hash

if ($sourceHash -ne $copiedHash) {
    throw "The copied CLI hash does not match the bundled CLI."
}

# Test the copied CLI before compiling/installing the shim.
& $copiedCodex --version

if ($LASTEXITCODE -ne 0) {
    throw "The copied CLI failed with exit code $LASTEXITCODE."
}

$escapedCopiedCodex = $copiedCodex.Replace('"', '""')

$shimSource = @'
using System;
using System.Runtime.InteropServices;
using System.Text;

internal static class CodexCwdShim
{
    private const string RealCodex = @"__REAL_CODEX__";

    private const int STARTF_USESTDHANDLES = 0x00000100;
    private const int STD_INPUT_HANDLE = -10;
    private const int STD_OUTPUT_HANDLE = -11;
    private const int STD_ERROR_HANDLE = -12;
    private const uint INFINITE = 0xFFFFFFFF;

    [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
    private struct STARTUPINFO
    {
        public int cb;
        public string lpReserved;
        public string lpDesktop;
        public string lpTitle;
        public int dwX;
        public int dwY;
        public int dwXSize;
        public int dwYSize;
        public int dwXCountChars;
        public int dwYCountChars;
        public int dwFillAttribute;
        public int dwFlags;
        public short wShowWindow;
        public short cbReserved2;
        public IntPtr lpReserved2;
        public IntPtr hStdInput;
        public IntPtr hStdOutput;
        public IntPtr hStdError;
    }

    [StructLayout(LayoutKind.Sequential)]
    private struct PROCESS_INFORMATION
    {
        public IntPtr hProcess;
        public IntPtr hThread;
        public uint dwProcessId;
        public uint dwThreadId;
    }

    [DllImport("kernel32.dll", CharSet = CharSet.Unicode)]
    private static extern IntPtr GetCommandLineW();

    [DllImport(
        "kernel32.dll",
        CharSet = CharSet.Unicode,
        SetLastError = true)]
    private static extern bool SetCurrentDirectoryW(string path);

    [DllImport("kernel32.dll")]
    private static extern IntPtr GetStdHandle(int handle);

    [DllImport(
        "kernel32.dll",
        CharSet = CharSet.Unicode,
        SetLastError = true)]
    private static extern bool CreateProcessW(
        string applicationName,
        StringBuilder commandLine,
        IntPtr processAttributes,
        IntPtr threadAttributes,
        bool inheritHandles,
        uint creationFlags,
        IntPtr environment,
        string currentDirectory,
        ref STARTUPINFO startupInfo,
        out PROCESS_INFORMATION processInformation);

    [DllImport("kernel32.dll")]
    private static extern uint WaitForSingleObject(
        IntPtr handle,
        uint milliseconds);

    [DllImport("kernel32.dll", SetLastError = true)]
    private static extern bool GetExitCodeProcess(
        IntPtr process,
        out uint exitCode);

    [DllImport("kernel32.dll")]
    private static extern bool CloseHandle(IntPtr handle);

    private static string GetRawArgumentTail()
    {
        string commandLine =
            Marshal.PtrToStringUni(GetCommandLineW()) ?? "";

        int i = 0;

        while (i < commandLine.Length &&
               char.IsWhiteSpace(commandLine[i]))
        {
            i++;
        }

        if (i < commandLine.Length &&
            commandLine[i] == '"')
        {
            i++;

            while (i < commandLine.Length &&
                   commandLine[i] != '"')
            {
                i++;
            }

            if (i < commandLine.Length)
            {
                i++;
            }
        }
        else
        {
            while (i < commandLine.Length &&
                   !char.IsWhiteSpace(commandLine[i]))
            {
                i++;
            }
        }

        return commandLine.Substring(i);
    }

    public static int Main()
    {
        string profile = Environment.GetFolderPath(
            Environment.SpecialFolder.UserProfile);

        if (!SetCurrentDirectoryW(profile))
        {
            return Marshal.GetLastWin32Error();
        }

        // Prevent recursion when the real CLI starts child processes.
        Environment.SetEnvironmentVariable(
            "CODEX_CLI_PATH",
            RealCodex,
            EnvironmentVariableTarget.Process);

        STARTUPINFO startupInfo = new STARTUPINFO();
        startupInfo.cb = Marshal.SizeOf(typeof(STARTUPINFO));
        startupInfo.dwFlags = STARTF_USESTDHANDLES;
        startupInfo.hStdInput =
            GetStdHandle(STD_INPUT_HANDLE);
        startupInfo.hStdOutput =
            GetStdHandle(STD_OUTPUT_HANDLE);
        startupInfo.hStdError =
            GetStdHandle(STD_ERROR_HANDLE);

        StringBuilder childCommandLine = new StringBuilder(
            "\"" + RealCodex + "\"" + GetRawArgumentTail());

        PROCESS_INFORMATION processInformation;

        bool started = CreateProcessW(
            RealCodex,
            childCommandLine,
            IntPtr.Zero,
            IntPtr.Zero,
            true,
            0,
            IntPtr.Zero,
            profile,
            ref startupInfo,
            out processInformation);

        if (!started)
        {
            return Marshal.GetLastWin32Error();
        }

        try
        {
            WaitForSingleObject(
                processInformation.hProcess,
                INFINITE);

            uint exitCode;

            if (!GetExitCodeProcess(
                    processInformation.hProcess,
                    out exitCode))
            {
                return Marshal.GetLastWin32Error();
            }

            return unchecked((int)exitCode);
        }
        finally
        {
            CloseHandle(processInformation.hThread);
            CloseHandle(processInformation.hProcess);
        }
    }
}
'@

$shimSource = $shimSource.Replace(
    "__REAL_CODEX__",
    $escapedCopiedCodex)

$shimPath = Join-Path $binDir "codex-cwd-shim.exe"

# Preserve an existing shim instead of deleting it.
if (Test-Path -LiteralPath $shimPath) {
    $backupPath = "$shimPath.backup-$(Get-Date -Format yyyyMMdd-HHmmss)"

    Move-Item `
        -LiteralPath $shimPath `
        -Destination $backupPath

    Write-Host "Previous shim backed up to: $backupPath"
}

Add-Type `
    -TypeDefinition $shimSource `
    -Language CSharp `
    -OutputAssembly $shimPath `
    -OutputType ConsoleApplication

# Test the shim before modifying the user environment.
& $shimPath --version

if ($LASTEXITCODE -ne 0) {
    throw "The shim test failed with exit code $LASTEXITCODE. CODEX_CLI_PATH was not changed."
}

[Environment]::SetEnvironmentVariable(
    "CODEX_CLI_PATH",
    $shimPath,
    "User")

Write-Host ""
Write-Host "Workaround installed successfully."
Write-Host "Package version: $($pkg.Version)"
Write-Host "Copied CLI: $copiedCodex"
Write-Host "Shim: $shimPath"
Write-Host "Restart Codex Desktop."

Expected test output:

codex-cli 0.150.0-alpha.8
Workaround installed successfully.

Why the helper executables are necessary

Copying only codex.exe caused these additional failures:

failed to spawn code-mode host:
codex-code-mode-host.exe was not found

Then:

orchestrator_helper_launch_failed:
codex-windows-sandbox-setup.exe was not found

Finally:

CreateProcessWithLogonW failed: 2

The final error disappeared after copying:

codex-command-runner.exe

The working directory therefore contains:

%USERPROFILE%\.codex\bin\
├── codex-cwd-shim.exe
├── codex-real-<desktop-version>.exe
├── codex-code-mode-host.exe
├── codex-command-runner.exe
└── codex-windows-sandbox-setup.exe

After restarting Codex Desktop, code-mode tool execution and DOCX reading both succeeded.

Rollback

Run this outside Codex Desktop:

[Environment]::SetEnvironmentVariable(
    "CODEX_CLI_PATH",
    $null,
    "User")

Then completely quit and restart Codex Desktop.

The copied files can remain in %USERPROFILE%\.codex\bin; without CODEX_CLI_PATH, Codex will not use the shim.

Caveat

This is an unofficial, version-specific workaround. After a Codex Desktop update, rerun the script so the copied CLI and helper executables match the newly installed package version. Do not change ACLs or take ownership of C:\Program Files\WindowsApps.

---

这份说明的重点是：原帖的 CWD shim 思路是正确的，但 Microsoft Store/MSIX 版本还受到 WindowsApps 执行权限限制，所以必须复制 CLI 以及三个辅助程序到用户目录。

具体是怎么操作的

下面是一个可直接粘贴到 [GitHub Issue #32759 ]( #32759 ) 的英文说明。它总结了我们实际遇到的所有错误、最终生效的代码和回滚方式。 ## WindowsApps 变体：在使用 CWD shim 之前，请复制捆绑的 CLI 和辅助程序可执行文件。 我确认了与 CWD 相关的解决方法，但在我的 Microsoft Store/MSIX 安装中，原始方法需要额外一个步骤。 ### 测试环境 Codex桌面版：26.820.9563.0 捆绑式 CLI：codex-cli 0.150.0-alpha.8 安装类型：Microsoft Store/MSIXC:\Program Files\WindowsApps 初始错误：code-mode host exited during handshake ### 附加问题 直接从未打包的 PowerShell 进程启动捆绑的 CLI 失败： `` Program "codex.exe" failed to run: Access is denied. Exit code: 5 ` 一个垫片直接指向： ` C:\Program Files\WindowsApps\...\app\resources\codex.exe ` 也导致 Codex Desktop 在启动时失败： ` ChatGPT failed to start code=5 Codex app-server websocket closed ` 可行的解决方案是： 1. 复制官方捆绑包codex.exe外部WindowsApps。 2. 复制它的三个同级辅助可执行文件。 3. 编译一个转发垫片，该垫片： * 将 CWD 更改为%USERPROFILE%； * 将子程序CODEX_CLI_PATH指向复制的 CLI； * 转发原始的命令行参数； * 直接继承 stdin/stdout/stderr 句柄。 4. 将用户级别设置CODEX_CLI_PATH为 shim。 5. 重启 Codex Desktop。 ### 安装脚本 请先完全退出 Codex Desktop，然后在全新的 Windows PowerShell 会话中运行以下命令： $ErrorActionPreference = "Stop" # Locate the current MSIX installation. $pkg = Get-AppxPackage -Name OpenAI.Codex | Sort-Object Version -Descending | Select-Object -First 1 if (-not $pkg) { throw "OpenAI.Codex MSIX package was not found." } $sourceDir = Join-Path -Path $pkg.InstallLocation -ChildPath "app\resources" $binDir = Join-Path $env:USERPROFILE ".codex\bin" New-Item -ItemType Directory -Path $binDir -Force | Out-Null # Copy the CLI outside WindowsApps so an unpackaged shim can execute it. $sourceCodex = Join-Path $sourceDir "codex.exe" $copiedCodex = Join-Path $binDir ("codex-real-{0}.exe" -f $pkg.Version) $helperNames = @( "codex-code-mode-host.exe", "codex-command-runner.exe", "codex-windows-sandbox-setup.exe" ) $requiredFiles = @("codex.exe") + $helperNames foreach ($name in $requiredFiles) { $sourceFile = Join-Path $sourceDir $name if (-not (Test-Path -LiteralPath $sourceFile)) { throw "Required bundled file was not found: $sourceFile" } } Copy-Item -LiteralPath $sourceCodex -Destination $copiedCodex -Force foreach ($name in $helperNames) { Copy-Item -LiteralPath (Join-Path $sourceDir $name) -Destination (Join-Path $binDir $name) -Force } # Verify that the copied CLI is byte-identical to the bundled CLI. $sourceHash = (Get-FileHash -LiteralPath $sourceCodex -Algorithm SHA256).Hash $copiedHash = (Get-FileHash -LiteralPath $copiedCodex -Algorithm SHA256).Hash if ($sourceHash -ne $copiedHash) { throw "The copied CLI hash does not match the bundled CLI." } # Test the copied CLI before compiling/installing the shim. & $copiedCodex --version if ($LASTEXITCODE -ne 0) { throw "The copied CLI failed with exit code $LASTEXITCODE." } $escapedCopiedCodex = $copiedCodex.Replace('"', '""') $shimSource = @' using System; using System.Runtime.InteropServices; using System.Text; internal static class CodexCwdShim { private const string RealCodex = @"__REAL_CODEX__"; private const int STARTF_USESTDHANDLES = 0x00000100; private const int STD_INPUT_HANDLE = -10; private const int STD_OUTPUT_HANDLE = -11; private const int STD_ERROR_HANDLE = -12; private const uint INFINITE = 0xFFFFFFFF; [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)] private struct STARTUPINFO { public int cb; public string lpReserved; public string lpDesktop; public string lpTitle; public int dwX; public int dwY; public int dwXSize; public int dwYSize; public int dwXCountChars; public int dwYCountChars; public int dwFillAttribute; public int dwFlags; public short wShowWindow; public short cbReserved2; public IntPtr lpReserved2; public IntPtr hStdInput; public IntPtr hStdOutput; public IntPtr hStdError; } [StructLayout(LayoutKind.Sequential)] private struct PROCESS_INFORMATION { public IntPtr hProcess; public IntPtr hThread; public uint dwProcessId; public uint dwThreadId; } [DllImport("kernel32.dll", CharSet = CharSet.Unicode)] private static extern IntPtr GetCommandLineW(); [DllImport( "kernel32.dll", CharSet = CharSet.Unicode, SetLastError = true)] private static extern bool SetCurrentDirectoryW(string path); [DllImport("kernel32.dll")] private static extern IntPtr GetStdHandle(int handle); [DllImport( "kernel32.dll", CharSet = CharSet.Unicode, SetLastError = true)] private static extern bool CreateProcessW( string applicationName, StringBuilder commandLine, IntPtr processAttributes, IntPtr threadAttributes, bool inheritHandles, uint creationFlags, IntPtr environment, string currentDirectory, ref STARTUPINFO startupInfo, out PROCESS_INFORMATION processInformation); [DllImport("kernel32.dll")] private static extern uint WaitForSingleObject( IntPtr handle, uint milliseconds); [DllImport("kernel32.dll", SetLastError = true)] private static extern bool GetExitCodeProcess( IntPtr process, out uint exitCode); [DllImport("kernel32.dll")] private static extern bool CloseHandle(IntPtr handle); private static string GetRawArgumentTail() { string commandLine = Marshal.PtrToStringUni(GetCommandLineW()) ?? ""; int i = 0; while (i < commandLine.Length && char.IsWhiteSpace(commandLine[i])) { i++; } if (i < commandLine.Length && commandLine[i] == '"') { i++; while (i < commandLine.Length && commandLine[i] != '"') { i++; } if (i < commandLine.Length) { i++; } } else { while (i < commandLine.Length && !char.IsWhiteSpace(commandLine[i])) { i++; } } return commandLine.Substring(i); } public static int Main() { string profile = Environment.GetFolderPath( Environment.SpecialFolder.UserProfile); if (!SetCurrentDirectoryW(profile)) { return Marshal.GetLastWin32Error(); } // Prevent recursion when the real CLI starts child processes. Environment.SetEnvironmentVariable( "CODEX_CLI_PATH", RealCodex, EnvironmentVariableTarget.Process); STARTUPINFO startupInfo = new STARTUPINFO(); startupInfo.cb = Marshal.SizeOf(typeof(STARTUPINFO)); startupInfo.dwFlags = STARTF_USESTDHANDLES; startupInfo.hStdInput = GetStdHandle(STD_INPUT_HANDLE); startupInfo.hStdOutput = GetStdHandle(STD_OUTPUT_HANDLE); startupInfo.hStdError = GetStdHandle(STD_ERROR_HANDLE); StringBuilder childCommandLine = new StringBuilder( "\"" + RealCodex + "\"" + GetRawArgumentTail()); PROCESS_INFORMATION processInformation; bool started = CreateProcessW( RealCodex, childCommandLine, IntPtr.Zero, IntPtr.Zero, true, 0, IntPtr.Zero, profile, ref startupInfo, out processInformation); if (!started) { return Marshal.GetLastWin32Error(); } try { WaitForSingleObject( processInformation.hProcess, INFINITE); uint exitCode; if (!GetExitCodeProcess( processInformation.hProcess, out exitCode)) { return Marshal.GetLastWin32Error(); } return unchecked((int)exitCode); } finally { CloseHandle(processInformation.hThread); CloseHandle(processInformation.hProcess); } } } '@ $shimSource = $shimSource.Replace( "__REAL_CODEX__", $escapedCopiedCodex) $shimPath = Join-Path $binDir "codex-cwd-shim.exe" # Preserve an existing shim instead of deleting it. if (Test-Path -LiteralPath $shimPath) { $backupPath = "$shimPath.backup-$(Get-Date -Format yyyyMMdd-HHmmss)" Move-Item -LiteralPath $shimPath -Destination $backupPath Write-Host "Previous shim backed up to: $backupPath" } Add-Type -TypeDefinition $shimSource -Language CSharp -OutputAssembly $shimPath -OutputType ConsoleApplication # Test the shim before modifying the user environment. & $shimPath --version if ($LASTEXITCODE -ne 0) { throw "The shim test failed with exit code $LASTEXITCODE. CODEX_CLI_PATH was not changed." } [Environment]::SetEnvironmentVariable( "CODEX_CLI_PATH", $shimPath, "User") Write-Host "" Write-Host "Workaround installed successfully." Write-Host "Package version: $($pkg.Version)" Write-Host "Copied CLI: $copiedCodex" Write-Host "Shim: $shimPath" Write-Host "Restart Codex Desktop." 预期测试输出： ` codex-cli 0.150.0-alpha.8 Workaround installed successfully. ` ### 为什么需要辅助可执行文件 复制操作只codex.exe导致了以下这些额外的故障： ` failed to spawn code-mode host: codex-code-mode-host.exe was not found ` 然后： ` orchestrator_helper_launch_failed: codex-windows-sandbox-setup.exe was not found ` 最后： ` CreateProcessWithLogonW failed: 2 ` 复制后，最后一个错误消失了： ` codex-command-runner.exe ` 因此，工作目录包含： ` %USERPROFILE%\.codex\bin\ ├── codex-cwd-shim.exe ├── codex-real-<desktop-version>.exe ├── codex-code-mode-host.exe ├── codex-command-runner.exe └── codex-windows-sandbox-setup.exe ` 重启 Codex Desktop 后，代码模式工具执行和 DOCX 读取均成功。 ### 回滚 在 Codex Desktop 之外运行此命令： [Environment]::SetEnvironmentVariable( "CODEX_CLI_PATH", $null, "User") 然后完全退出并重新启动 Codex Desktop。 复制的文件可以保留在%USERPROFILE%\.codex\bin; 如果没有CODEX_CLI_PATH，Codex 将不会使用 shim。 ### 注意 这是一个非官方的、特定于版本的解决方法。Codex Desktop 更新后，请重新运行脚本，以确保复制的 CLI 和辅助可执行文件与新安装的软件包版本匹配。请勿更改 ACL 或获取其所有权C:\Program Files\WindowsApps`。 这份声明限制的重点是：原帖的 CWD shim 思路是正确的，但 Microsoft Store/MSIX 版本仍然受到 WindowsApps 执行权限，所以必须复制 CLI 以及三个辅助程序到用户目录。 > 具体是怎么操作的

这是我让codex帮我总结的，看能否帮到大家

I can add a detailed diagnostic data point for the same failure pattern.

Possibly related: #41241

Environment

• Windows
• Codex Desktop: 26.820.71523
• Codex app-server: 0.150.0-alpha.8
• Failing model: GPT-5.6 Terra
• Working comparison: GPT-5.5
• Windows sandbox configuration: elevated

Minimal reproduction

On the same machine and the same Codex installation:

1. Select GPT-5.6 Terra.
2. Ask it to run:

Get-Date

1. GPT-5.6 fails before PowerShell is launched:

code-mode host exited during handshake

1. Switch to GPT-5.5.
2. Run exactly the same Get-Date.
3. The command succeeds.

PowerShell, cmd.exe, and Git were also independently tested outside Codex and work normally.

GPT-5.5 vs GPT-5.6 execution path

The local session records show different execution paths.

GPT-5.5:

function_call
-> exec_command
-> unified_exec
-> pwsh.exe
-> success

The successful execution reports:

status="completed"
exit_code=0

GPT-5.6 Terra:

custom_tool_call
-> exec / code-mode
-> codex-code-mode-host.exe
-> handshake failure

followed by:

code-mode host exited during handshake

Codex internal error

The structured Codex log reports:

level=ERROR
target=codex_core::tools::router
file=core\src\tools\router.rs:225
dispatch_tool_call_with_code_mode_result
error=code-mode host exited during handshake

codex-code-mode-host.exe exists in the current Codex installation, so this is not the same observed failure as a missing host executable.

Model tool-mode observation

The local models_cache.json shows:

gpt-5.6-sol   -> tool_mode: code_mode_only
gpt-5.6-terra -> tool_mode: code_mode_only
gpt-5.6-luna  -> tool_mode: code_mode_only

GPT-5.5 does not have this field.

I am not suggesting that code_mode_only itself is incorrect. The relevant observation is that GPT-5.6 reaches the code-mode host path, while GPT-5.5 successfully uses the normal unified-exec path on the same machine.

Main app/runtime health

Codex Desktop / app-server initialization succeeds:

stdio_transport_spawned
initialize_handshake_result ... outcome=success

Primary runtime diagnostics also report:

installed=true
problemCount=0

Windows Event Log investigation

I performed a read-only Windows Event Log investigation covering approximately:

2026-08-28 12:28–12:42

which includes repeated GPT-5.6 failures.

No codex-code-mode-host.exe crash or security-block event was found.

Specifically:

• No matching Application Error event
• No matching Windows Error Reporting event
• No matching Application Popup event
• No Exception Code / NTSTATUS / Exit Code was recorded
• No Faulting Module was recorded

No matching blocking event was found in:

Microsoft-Windows-CodeIntegrity/Operational
Microsoft-Windows-AppLocker/EXE and DLL
Microsoft-Windows-AppLocker/MSI and Script
Microsoft-Windows-AppLocker/Packaged app-Deployment
Microsoft-Windows-AppLocker/Packaged app-Execution
Microsoft-Windows-Windows Defender/Operational

Security event 4688 also did not provide a matching codex-code-mode-host.exe process-creation record. Sysmon is not installed/enabled on this machine.

So far, there is no Windows Event Log evidence that Defender, AppLocker, or Code Integrity blocked codex-code-mode-host.exe.

Current assessment

This appears specific to the GPT-5.6 code-mode execution path rather than PowerShell, cmd.exe, Git, or the GPT-5.5 unified-exec path.

On the same machine and installation, GPT-5.5 executes local commands successfully while GPT-5.6 consistently fails while initializing the code-mode host.

I do not yet have evidence proving whether the host exits because of a Codex regression, a runtime initialization issue, or a machine-specific Windows interaction.

Workaround

Switching from GPT-5.6 Terra to GPT-5.5 restores local command execution.

Related reports

• #41241 appears to report the same general Windows handshake failure pattern.
• #41088 may be related to Windows 26.820 local-host regressions, but that report includes an explicit os error 2 / file not found failure. On this machine, codex-code-mode-host.exe exists and the observed failure occurs during handshake.

I encountered the exact same error on Windows: code-mode host exited during handshake The impact was broader than directory access or a single tool call. While the issue was present: Minimal local commands such as Get-Date and Get-Location failed before execution. Web/finance requests failed before being dispatched. Asking Codex to install skills from GitHub also failed. The built-in skill-installer could not even read its own installation instructions or start the GitHub download script. Reading an already-installed skill's SKILL.md failed with the same handshake error. Restarting only the Codex app did not resolve the problem. The same failure occurred in another Codex task, so it was not limited to one project or working directory. Examples of GitHub skill repositories that could not be installed or accessed through Codex at that time included: https://github.com/quantskills/quantskills https://github.com/deluo/fund-dca-skill https://github.com/Garyjie/neodata-financial-search The GitHub requests did not appear to start. The failure occurred earlier, while the local code-mode host was starting. I found this Windows registry value explicitly set to 0: `` HKLM\SYSTEM\CurrentControlSet\Control\Session Manager SafeDllSearchMode REG_DWORD 0x0 I changed it from an elevated terminal: reg.exe add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v SafeDllSearchMode /t REG_DWORD /d 1 /f After verifying that it was 0x1 and performing a full Windows restart: - Local commands executed normally. - codex-code-mode-host.exe started successfully. - Installed skill files could be read again. - External financial-data skill calls and web searches worked again. Environment: - Windows version: 25H2 - Windows build: 26200.9168 - Codex App version: [paste version from “About Codex”] This is one-machine evidence, not proof that SafeDllSearchMode=0 causes every occurrence. However, the before/after behavior was clear and suggests investigating Windows DLL search order during codex-code-mode-host.exe startup. ``

I meet the same problem and this works for me

Confirmed fixed on my machine.

SafeDllSearchMode was explicitly set to 0. After changing it to 1 and fully restarting Windows, GPT-5.6 local tool execution works normally again.

The same commands that previously failed with:
code-mode host exited during handshake

now execute successfully.

Additional reproduction notes from the same user/session:

• Platform: Microsoft Windows NT 10.0.19045.0 x64
• The failure happened while trying to summarize a local DOCX in Codex Desktop.
• With gpt-5.6-sol, local document/tool execution repeatedly failed before any DOCX parsing with:

code-mode host exited during handshake

• The same task later switched to gpt-5.6-terra, but the already-wedged local code-mode/tool host still failed with the same handshake error. This suggests there may be task-level/runtime state involved, not only a single model response.
• After switching to gpt-5.5, local tools initialized successfully again. I was able to read a local skill file and use GitHub tooling from the same Windows environment.
• The document itself does not appear to be the root cause, because the failure occurs before the document component/parser runs. A separate visual DOCX render attempt also lacked soffice/LibreOffice, but that is a different issue from this handshake failure.

Expected behavior: switching models should not leave the local tool host in a broken handshake state, and gpt-5.6-sol/gpt-5.6-terra should be able to initialize the same local document/tool execution path that works under gpt-5.5.