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.