config.toml MCP paths stale after auto-update — node_repl fails with 'os error 3'

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

• #25878

Powered by Codex Action

Adding one possibly related root cause from another Windows repro, in case it helps triage this stale-path issue.

In my case, the stale path was not only in config.toml; chrome-native-hosts-v2.json also had paths.codexCliPath pointing to an old hash directory whose codex.exe no longer existed. That stale CLI path made Codex app-server startup / Browser policy config reads fail with os error 3.

One extra user-facing problem: the Browser layer eventually surfaced this as an enterprise network policy denial, even though the actual root cause was a missing configured codex.exe path. It may be worth checking/regenerating both CODEX_CLI_PATH and paths.codexCliPath after updates.

I wrote up the focused repro/details here: #28474

I hit a closely related stale-runtime case on Windows 10 after moving from an npm-installed CLI to the standalone Windows CLI and updating Codex Desktop.

In my case the stale state was not only in config.toml; both native-host config files still pointed at an older Codex runtime:

C:\Users\<user>\.codex\chrome-native-hosts.json
C:\Users\<user>\AppData\Local\OpenAI\Codex\chrome-native-hosts.json

Both contained:

{
  "codexCliPath": "C:\\Users\\<user>\\AppData\\Local\\OpenAI\\Codex\\bin\\7dea4a003bc76627\\codex.exe",
  "nodePath": "C:\\Users\\<user>\\AppData\\Local\\OpenAI\\Codex\\bin\\5b9024f90663758b\\node.exe",
  "nodeReplPath": "C:\\Users\\<user>\\AppData\\Local\\OpenAI\\Codex\\bin\\34ab3e1324cc55b5\\node_repl.exe",
  "pluginVersion": "26.527.31326",
  "resourcesPath": "C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\\app\\resources"
}

The referenced codex.exe was:

codex-cli 0.135.0-alpha.1

After updating/installing the standalone CLI, the active CLI was:

C:\Users\<user>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe
codex-cli 0.140.0

After launching the updated Desktop app, a newer Desktop runtime existed:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\f1c7ee7a13db5fed\codex.exe
codex-cli 0.140.0-alpha.2

and config.toml had been updated to use that newer runtime via [mcp_servers.node_repl.env] CODEX_CLI_PATH, but the chrome-native-hosts.json files still referenced the old 0.135.0-alpha.1 codex.exe.

That made it possible for helper/browser/native-host flows to launch an older Codex runtime even while the foreground CLI was 0.140.0.

I agree the real fix is likely in the Desktop/plugin sync code that rewrites these files. Since that path looks outside the public CLI code, I prepared a narrower public-repo diagnostic improvement instead:

https://github.com/starriet9/codex/tree/doctor/desktop-runtime-diagnostics

Candidate change summary:

• Add a codex doctor check named desktop.browser_runtime.
• Read the effective node_repl MCP env from the already-loaded Config.
• Compare CODEX_CLI_PATH / BROWSER_USE_CODEX_APP_VERSION against values in:
• %USERPROFILE%\.codex\chrome-native-hosts.json
• %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts.json
• Warn when codexCliPath points to a missing/stale runtime or does not match the configured CODEX_CLI_PATH.
• Warn when pluginVersion is stale relative to the configured/installed bundled plugin version.

Local verification:

cargo fmt --check
cargo test -p codex-cli desktop_runtime

Both passed on Windows.

I am not opening a PR yet because docs/contributing.md says external PRs are by invitation only. If the team thinks a codex doctor diagnostic is useful while the Desktop sync fix is handled elsewhere, I can open a focused PR from the branch above.

Follow-up after validating the separate /app Desktop handoff fix from #28667:

Opening the same thread successfully in Codex Desktop did not regenerate these native-host files on this Windows 10 machine:

C:\Users\<user>\.codex\chrome-native-hosts.json
C:\Users\<user>\AppData\Local\OpenAI\Codex\chrome-native-hosts.json

Both files still point to the older runtime:

codexCliPath -> ...\AppData\Local\OpenAI\Codex\bin\7dea4a003bc76627\codex.exe
version      -> codex-cli 0.135.0-alpha.1
pluginVersion -> 26.527.31326
resourcesPath -> ...\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\resources

while the currently configured Desktop/Node REPL runtime in config.toml points to the newer runtime:

CODEX_CLI_PATH -> ...\AppData\Local\OpenAI\Codex\bin\f1c7ee7a13db5fed\codex.exe
version        -> codex-cli 0.140.0-alpha.2
BROWSER_USE_CODEX_APP_VERSION -> 26.609.41114

So in this repro, launching/opening Desktop successfully is not enough by itself to repair stale chrome-native-hosts.json. That reinforces the need for either Desktop/plugin sync regeneration or at least a codex doctor diagnostic for this specific mismatch.

Local repair/validation follow-up:

1. I backed up and quarantined the two stale native-host files instead of editing them in place:

%USERPROFILE%\.codex\chrome-native-hosts.json
%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts.json

1. After relaunching Codex Desktop through the registered codex:// protocol, config.toml was refreshed to a newer Desktop/runtime:

Codex Desktop package: 26.611.7849.0
BROWSER_USE_CODEX_APP_VERSION: 26.611.61049
CODEX_CLI_PATH: ...\AppData\Local\OpenAI\Codex\bin\330bd0cba6496126\codex.exe
CODEX_CLI_PATH version: codex-cli 0.140.0-alpha.19

1. The stale 0.135.0-alpha.1 native-host files were not regenerated automatically after Desktop launch. Both canonical paths remained missing after launch:

%USERPROFILE%\.codex\chrome-native-hosts.json
%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts.json

1. After quarantining the stale files and relaunching Desktop, no 0.135.0-alpha.1 Codex/helper process was observed. codex doctor --summary --ascii still reported the standalone install, config, and state DB as healthy.

So the local stale-runtime hazard is mitigated by quarantining the old files, and Desktop does refresh config.toml; however, Desktop launch alone still does not recreate/repair chrome-native-hosts.json. That keeps the diagnostic gap relevant: stale native-host files can persist across updates, and if removed, there does not appear to be an obvious doctor/remediation path that tells the user whether those files are intentionally absent or need regeneration.

same issue here
019ef774-3d79-7f01-b686-47f63bc06b4b

I experienced what appears to be the same issue and wanted to add one additional observation.

Immediately after Codex performed an automatic update on startup, I started getting:

⚠ MCP client for `node_repl` failed to start:
MCP startup failed: The system cannot find the path specified. (os error 3)

⚠ MCP startup incomplete (failed: node_repl)

In my case, config.toml still referenced the old runtime hash:

...runtimes\cua_node\789504f803e82e2b\...

but the actual runtime had been updated to:

...runtimes\cua_node\a89897d3d9baa117\...

I confirmed the new runtime with:

Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\runtimes\cua_node" -Recurse -Filter node_repl.exe

Updating these three entries in config.toml to the new runtime hash immediately resolved the problem:

• mcp_servers.node_repl.command
• NODE_REPL_NODE_PATH
• NODE_REPL_NODE_MODULE_DIRS

This suggests the runtime was updated successfully, but the paths in config.toml were not updated accordingly.

Follow-up based on the newer stale-runtime reports above:

I updated the diagnostic branch to also check the node_repl runtime paths that can remain stale in config.toml after a Desktop/runtime update:

• mcp_servers.node_repl.command
• NODE_REPL_NODE_PATH
• NODE_REPL_NODE_MODULE_DIRS

The updated desktop.browser_runtime doctor check now warns when those configured paths point to missing runtime files/directories, even when no chrome-native-hosts.json file is present.

Branch:
https://github.com/starriet9/codex/tree/doctor/desktop-runtime-diagnostics

Local verification on Windows:

cargo fmt --check
cargo test -p codex-cli desktop_runtime

Both passed.

I am still not opening a PR directly because the contributing guide says external PRs are by invitation only, but this branch is available if a focused codex doctor diagnostic would be useful.

I maintain WinBridge Recovery for Windows Codex Desktop update/recovery state: https://github.com/zemeng5208/winbridge-recovery

This stale-path failure is directly within the project's current scope. WinBridge v3.1.1 does not assume that one path is authoritative after an app update; it resolves the current Store package/runtime first, then checks node_repl.command, CODEX_CLI_PATH, Node/runtime paths, plugin cache versions/latest, Native Host state, and app-server/native-host resource paths for references to removed hash/version directories.

The extra reports in this thread are especially important because the stale value can survive in more than config.toml: chrome-native-hosts*.json / v2 state can still launch or reference an older Desktop runtime even after the foreground config was updated. That creates exactly the kind of split-brain state WinBridge is designed to detect.

For this class of os error 3 failure, the tool can rebuild user-owned runtime/config references against the currently installed official package and validate that the target executables/paths actually exist before switching state, with backups/rollback. It does not patch the AppX package or bypass Browser policy. Also, if all local paths are current and the failure is an upstream runtime/tool-injection problem, it stops at diagnosis instead of claiming a fix.

I can reproduce a closely matching stale-runtime-path failure on Windows + WSL after updating the Codex App.

Environment

• Codex App: 26.820.60940
• Codex CLI: 0.149.1, launched directly inside WSL
• Platform: Windows 11 with WSL2
• Workspace: WSL Linux filesystem

Observed behavior

Starting Codex CLI inside WSL reports:

⚠ MCP client for `node_repl` failed to start: MCP startup failed: No such file or directory (os error 2)

⚠ MCP startup interrupted. The following servers were not initialized: codex_apps

⚠ MCP startup incomplete (failed: node_repl)

The WSL user configuration at ~/.codex/config.toml contains an App-generated mcp_servers.node_repl block whose command points to the following runtime:

/mnt/c/Users/<user>/AppData/Local/OpenAI/Codex/runtimes/cua_node/be1d88aa93cd4c41/bin/node_repl.exe

That runtime directory no longer exists.

The currently installed App runtime is:

/mnt/c/Users/<user>/AppData/Local/OpenAI/Codex/runtimes/cua_node/20832beba124f7a1/bin/node_repl.exe

The current executable exists and is executable.

The old runtime identifier is present in multiple generated settings, not only the MCP command. The affected settings include:

• mcp_servers.node_repl.command
• NODE_REPL_NODE_PATH
• NODE_REPL_NODE_MODULE_DIRS
• NODE_REPL_TRUSTED_CODE_PATHS
• shell_environment_policy.set.NODE_REPL_TRUSTED_CODE_PATHS

The Windows App-side Codex configuration already references the current runtime, while the WSL-side configuration still references the removed runtime.

This suggests that the App runtime update completed, but the App-generated node_repl configuration in the WSL Codex home was not refreshed before the old runtime was removed. This is an inference based on the observed paths; I have not confirmed the internal update path.

I have not modified the configuration yet.

Expected behavior

After an App/runtime update, generated node_repl paths in every Codex home used by the App or CLI should be refreshed before the previous hash-named runtime is removed.

Alternatively, the CLI should identify the missing configured command and provide an actionable repair message.

This may be related at the App/WSL configuration-lifecycle level to #40715, although that issue concerns an injected mcp_servers.codex_app transport rather than a stale node_repl executable path.

Confirmed the same stale-path regression on a newer Windows ARM64 package.

Environment:

• OpenAI.Codex Store package 26.825.3734.0 (Arm64)
• codex-cli 0.150.1
• Windows 11 Pro, build 28000, ARM64

Current read-only evidence from codex mcp get node_repl --json:

• node_repl is enabled.
• Its generated configuration still identifies app build 26.820.80927.
• The configured node_repl.exe path and its parent directory do not exist.
• The configured CODEX_CLI_PATH and NODE_REPL_NODE_PATH targets also do not exist.
• Every fresh TUI start reproduces MCP client for node_repl failed to start ... (os error 3).

This confirms that generated MCP paths from an older app build can survive at least one later Store update. No local paths or usernames are included in this public comment.

I uploaded logs and diagnostics through /feedback.

Uploaded thread: 01a0470d-0700-71b0-8afb-875b432c5088