[Windows][26.820.7780.0] Local execution fails to start after updating Codex Desktop

[InvisibleSix]

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

OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0

What subscription do you have?

PLUS

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After updating Codex Desktop to 26.820.7780.0, all new local tasks fail before any command is executed.

Observed user-facing errors include:

Unable to read: local execution environment failed to start.
Unable to read: local command execution service handshake failed.

One observed underlying error was:

failed to spawn code-mode host
C:\Users<redacted>\AppData\Local\OpenAI\Codex\bin\d0097be4feba73d0\codex-code-mode-host.exe:
The system cannot find the file specified. (os error 2)

The regression is specific to this Windows machine after upgrading to 26.820. The root cause is not yet known.

What steps can reproduce the bug?

1. Use a working Codex Desktop installation on Windows 10.0.26200.0.
2. Update the app to 26.820.7780.0.
3. Create a new local task.
4. Request a trivial local command, such as listing a directory.
5. Observe that local execution fails during startup or handshake, before the command runs.

The issue persists after:

1. Restarting Windows
2. Windows repair operations
3. A clean Codex configuration test
4. Recreating the CUA Node runtime

What is the expected behavior?

After an in-app update, a new local task should start normally and execute basic commands.
If a required local runtime component is unavailable, Codex should report the exact missing component and provide an automatic repair path instead of failing every local task with a generic startup or handshake error.

Additional information

I compared the affected PC with another PC where 26.820.7780.0 works normally:

1. Same Windows build
2. Same Codex App version
3. Same codex.exe hash
4. Same node_repl.exe hash
5. Configured named pipe matched the actual running named pipe on both PCs

Therefore, this does not appear to be a universally broken 26.820 release, but it is a reproducible machine-specific or state-specific regression triggered by the update.
Rolling back to the previous 26.818.61809 build restored local execution after completing the rollback procedure.
Please advise what additional diagnostics would be useful. I can provide sanitized Codex Desktop logs and process details.

[github-actions]

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

• Windows update regression: local execution fails because codex-code-mode-host.exe is missing from .sandbox-bin #40817

Powered by Codex Action

[MilkyWay008]

The failed to spawn code-mode-host ... d0097be4feba73d0\codex-code-mode-host.exe: The system cannot find the file specified (os error 2) is a missing-binary issue, not a config one, which is why the clean-config test didn't help. That hash subfolder not existing on disk after an update usually means AV quarantine or a half-extracted update, worth checking Defender's quarantine history for the codex bin path before reinstalling. If you have a second machine on the same build, copying the whole %LOCALAPPDATA%\OpenAI\Codex\bin\ folder over fixes it in minutes, I did exactly that once when an update dropped a helper. oh, btw, in case it might help that, I built a portable Hermes OTG repo, check it, imo it may be able to help you diagnose and figure out the fix in no time. https://github.com/MilkyWay008/Hermes-OTG

[zemeng5208]

This looks like a good match for the local runtime/helper materialization layer rather than a config-only failure: the app is trying to spawn %LOCALAPPDATA%\OpenAI\Codex\bin\d0097be4feba73d0\codex-code-mode-host.exe, but that helper is not present after the update, while another machine on the same Desktop build works.

I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

For this specific failure it can help diagnose/recover the per-user Codex runtime/helper staging layer: whether the expected hash/version directory exists, whether codex.exe / codex-code-mode-host.exe / related helpers were only partially materialized, whether stale .staging-* state or a file lock interrupted activation, and whether the user-side copies still match the currently installed official MSIX resources.

The important limitation is that this only addresses local state/materialization problems. It does not modify WindowsApps, bypass package protection, or guarantee a fix. If the current Desktop build itself is selecting the wrong helper hash/path, or repeatedly fails to materialize a valid helper from an Application Protected/EFS source, that remains an upstream Codex relocation/update bug and needs an OpenAI-side fix.

[micizi95]

I’m also seeing the Windows-side regression after the recent Codex update, with symptoms beyond the GPT-5.6 tool-call failure:

• Codex Desktop now takes a very long time to launch.
• Chats take a long time to load and can appear to hang/unresponsive.
• Local work is unreliable on GPT-5.6, while switching the same project/chat to GPT-5.5 restores command execution.

I added the GPT-5.6-specific reproduction to #41049 as well. This report is to confirm that the startup/chat-loading slowdown is also present on an affected Windows installation after the recent update.

Please consider whether these symptoms share the same 26.820 runtime/local-execution regression or represent two overlapping regressions. If there are diagnostic logs that would help isolate startup/chat loading versus code-mode host/tool-call failures, please document the recommended collection steps.

[InvisibleSix]

@MilkyWay008 @zemeng5208
I reproduced the issue again with OpenAI.Codex 26.820.9563.0 and collected additional evidence.

Important correction

The previously observed “missing codex-code-mode-host.exe” condition occurred later during a rollback/cache-version mismatch. It should not be treated as the confirmed root cause of the original 26.820 local-execution regression.
In the current clean reproduction, the host executable is present and valid.

Reproduction results

• App version: OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0
• AppX deployment completed successfully.
• Windows successfully validated and trusted the package.
• New local tasks still fail with:
  • Local execution environment failed to start
  • Local command execution service handshake failed
  • code-mode host exited during handshake
    The active app-server process was:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\d5f4c71927a04589\codex.exe

It was launched with:

-c features.code_mode_host=true app-server

Host executable integrity

The host executable exists in both locations:

C:\Program Files\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0\app\resources\codex-code-mode-host.exe
C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\d5f4c71927a04589\codex-code-mode-host.exe

Both copies have the same SHA-256 hash:

F081067C03AE746C22BED3B5106C2CF9C3EB3448E835E218DFCDAFAAF8569ED9

Both Authenticode signatures report:

Status: Valid

This rules out a missing host file, a corrupted MSIX copy, and a damaged per-user materialized copy in this reproduction.

Process monitoring result

A short-interval process monitor captured the host process:

ProcessId: 3356
Path: C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\d5f4c71927a04589\codex-code-mode-host.exe
ExitCodeHex: 0x00000000

The decimal ExitCode field was blank in the collector, so I do not want to overstate the exact exit status. However, the process was definitely created from the expected path and then disappeared during the handshake window.
There were no matching Windows Application events from:

• Application Error (1000)
• Windows Error Reporting (1001)
• .NET Runtime (1026)
  This does not look like a normal unhandled Windows crash. The current evidence suggests that the host starts successfully but exits before completing its parent/child handshake.

Security-software check

• Both host copies remain present and correctly signed.
• Exiting Huorong Security did not change the result.
• Closing other unrelated applications and services also did not resolve the failure.
• The same machine works again immediately after rolling back to 26.818.

Current assessment

The problem appears to be in the code-mode host initialization or handshake path, rather than MSIX installation or helper-file materialization.
A possible failure mode is that the host does not receive or retain the expected IPC/stdio/pipe handshake channel and exits early, while the parent codex.exe reports code-mode host exited during handshake. This is an inference from the observed behavior, not a confirmed source-level root cause.

Could a maintainer advise:

1. How to enable detailed codex-code-mode-host.exe startup/handshake logging?
2. Whether host stderr and the actual exit status can be surfaced in the desktop logs?
3. Which IPC transport or inherited handles are expected during the handshake?
4. Whether there are known 26.820 changes in the Windows code-mode-host bootstrap path?
5. What additional trace would be most useful for identifying why the host exits before completing the handshake?

I can provide sanitized desktop logs, AppX deployment events, hashes, signatures, and additional process traces if needed.

[InvisibleSix]

@micizi95
Additional controlled A/B result:
On the same affected Windows machine, with the same Codex Desktop installation, project, configuration, and security software state:
GPT-5.6 consistently fails to execute local tasks with the code-mode host handshake error.
Switching the same workload to GPT-5.5 restores local command execution immediately.
Rolling back Codex Desktop from 26.820.x to 26.818.x also restores normal operation.
This matches the model-specific behavior reported in #41049, #32759, and #38187.

Given that both copies of codex-code-mode-host.exe were present, had identical SHA-256 hashes, valid signatures, and the process was observed starting, this no longer appears to be a missing-file or antivirus-quarantine issue. It appears to be a GPT-5.6/code-mode compatibility regression in the newer runtime.

[InvisibleSix]

I performed an additional comparison between the working 26.818 build and the affected 26.820 build. The evidence suggests that this is not simply a missing executable or antivirus quarantine, but a regression in the newer local execution path used by GPT-5.6.

Controlled comparison:

• Codex Desktop 26.818.8289 / bundled CLI 0.149.0-alpha.4.3:
  GPT-5.6 local execution works.
• Codex Desktop 26.820.9563 / bundled CLI 0.150.0-alpha.8:
  GPT-5.6 fails during the Code Mode Host handshake, while GPT-5.5 works.

The same Windows account, workspace, configuration, and security-software state were used.

On 26.820:

• codex-code-mode-host.exe existed in both the App package and per-user cache.
• Both copies had the same SHA-256:
  F081067C03AE746C22BED3B5106C2CF9C3EB3448E835E218DFCDAFAAF8569ED9
• Both Authenticode signatures were valid.
• The Host process was observed starting from the expected directory.
• It exited before completing the handshake.
• Exiting Huorong and closing unrelated applications/services did not help.
• Rolling back to 26.818 immediately restored GPT-5.6 local execution.

I also compared the corresponding bundled Codex CLI versions. Between these builds, the model shell backend changed from shell_command to unified_exec.

The relevant source change is:

8a40095

This commit, “Standardize shell execution on unified exec (#39757),” modified 116 files, removed the legacy shell-command backend and fallback path, and standardized local command execution on unified_exec.

GPT-5.6 remained configured with:

• tool_mode: code_mode_only
• use_responses_lite: true

GPT-5.5 does not use the same code_mode_only route. This explains why switching only the model changes the result on the same affected installation.

Another relevant change increased the local Code Mode Host startup timeout from 10 to 30 seconds:

275ef85

The corresponding source returns code-mode host exited during handshake when the spawned Host process exits before producing the expected handshake data.

Current assessment:

The strongest hypothesis is a Windows regression in the unified_exec initialization or integration path when invoked through the GPT-5.6 Code Mode Host.

The exact internal exit point is not yet confirmed because the Host does not emit a useful crash or handshake diagnostic. However, the controlled 26.818 versus 26.820 comparison isolates the regression to the newer Desktop/CLI runtime and its local execution changes.

Current workarounds:

• Remain on Codex Desktop 26.818; or
• Use GPT-5.5 for local tasks on affected newer builds.