Misleading Browser policy error when configured Codex CLI path does not exist

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

• #27160

Powered by Codex Action

I hit the same failure mode on Windows Codex Desktop.

Environment:

• Codex app/browser bundle: 26.623.42026
• Codex CLI after repair: 0.142.3
• Codex home: %USERPROFILE%\.codex

Symptom:
Browser Use failed for every site with:
"Browser Use cannot access https://... because enterprise network policy blocks it."

Findings:

• configRequirements/read returned requirements: null, so this was not a real managed enterprise policy.
• DNS and TCP 443 were fine.
• CODEX_CLI_PATH in both the process/user environment and %USERPROFILE%\.codex\config.toml pointed to a missing path:

...\vendor\x86_64-pc-windows-msvc\codex\codex.exe

• The actual installed CLI path was:

...\vendor\x86_64-pc-windows-msvc\bin\codex.exe

Fix:

• Updated %USERPROFILE%\.codex\config.toml [mcp_servers.node_repl.env].CODEX_CLI_PATH
• Updated the user-level CODEX_CLI_PATH environment variable
• Fully exited and reopened Codex

Result:
Browser Use recovered. It could navigate to https://asabeko.com/, read the page title/DOM, scroll, and click the menu.

Extra note:
A config-only fix did not survive until the user-level environment variable was also corrected, because Codex appeared to regenerate the stale value on app restart. I hope this helps!

Adding another confirmation from Windows Codex Desktop 26.623.42026.

In this case the visible error was:

Browser Use cannot access http://localhost:3000 because enterprise network policy blocks it

The actual root cause was a stale Windows User environment variable:

CODEX_CLI_PATH=C:\Users\<user>\AppData\Local\OpenAI\Codex\bin.bak-...\<hash>\codex.exe

That path no longer existed. The current valid path was:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\<current-hash>\codex.exe

Important detail: fixing %USERPROFILE%\.codex\config.toml alone was not enough. After restarting Codex, config.toml reverted back to the stale bin.bak-... path because the user-level environment variable was still stale.

Fix applied:

[Environment]::SetEnvironmentVariable(
  "CODEX_CLI_PATH",
  "C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\<current-hash>\codex.exe",
  "User"
)

Then updated config.toml to the same valid path and fully restarted Codex/Chrome.

Result after restart:

• CODEX_CLI_PATH process env: valid path
• CODEX_CLI_PATH user env: valid path
• config.toml: valid path
• agent.browsers.list() showed both Chrome extension and IAB backends
• Chrome extension backend connected successfully
• http://localhost:3000 no longer failed with enterprise policy
• local page loaded successfully with HTTP 200, title/DOM readable

So the misleading enterprise-policy error can also be caused by a stale user-level CODEX_CLI_PATH that rewrites the config on app startup. It would help if Browser Use/app-server startup reported the effective CODEX_CLI_PATH source, e.g. process env vs user env vs machine env vs config, when the path does not exist.

Adding a focused diagnostic follow-up for the stale CODEX_CLI_PATH cases described above.

I updated the existing doctor diagnostic branch to also surface the Windows environment-variable layer that can keep reintroducing a stale CLI path:

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

Latest commit:
353bfe26f Diagnose stale CODEX_CLI_PATH env values

The desktop.browser_runtime doctor check now reports:

• process environment CODEX_CLI_PATH
• Windows User environment CODEX_CLI_PATH
• Windows Machine environment CODEX_CLI_PATH

and warns when any of those values:

• points to a missing codex.exe
• disagrees with the CODEX_CLI_PATH configured through mcp_servers.node_repl.env

This is meant as a diagnostic only, not the underlying Desktop sync fix. It should make cases like “fixing config.toml does not stick because a stale User environment variable rewrites it on restart” visible in codex doctor.

Local verification on Windows:

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

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

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

This failure chain is directly within the diagnostic/recovery scope of the project. WinBridge v3.1.1 resolves the currently installed Store package/runtime and checks stale Codex CLI references across config.toml, Node REPL environment, Native Host/v2 state and related runtime paths before classifying a Browser failure as policy-related.

That distinction matters here because a missing codex.exe can make the Browser policy/config service unavailable and then surface as a misleading enterprise-policy denial. WinBridge validates that the effective configured path actually exists and can repair user-owned stale runtime/config references against the current official installation, with backups and post-repair validation.

The follow-up comments here also show another source that should be checked: a stale Windows User-level CODEX_CLI_PATH can rewrite a repaired config.toml on restart. I am treating environment/config/native-host provenance as part of the same split-brain diagnosis rather than assuming config.toml alone is authoritative.

It does not bypass real enterprise policy. If policy is genuinely enforced, or all local runtime paths are healthy and Browser still fails upstream, the tool should stop at diagnosis rather than override that boundary.