›_ Codex Issues
Codex Issues / #19562

Windows browser-use external navigation fails when Codex helper bin path is missing

Open 💬 7 comments Opened Apr 25, 2026 by michaelbuckner
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What happened?

On Windows Codex Desktop, @browser-use could bootstrap the IAB backend and create/list tabs, but external navigation failed before loading the page.

The failure occurred on tab.goto("https://example.com/") during the authenticated site-status check:

failed to start codex app-server: The system cannot find the path specified. (os error 3)

Local navigation to http://127.0.0.1:<port>/ worked, so the browser backend itself was alive. External navigation was blocked by the host/app-server helper path used by nodeRepl.fetch.

Environment

  • OS: Windows
  • Codex Desktop package path: OpenAI.Codex_26.422.3464.0_x64__2p2nqsd0c76g0
  • Codex app-server: 0.125.0-alpha.3
  • browser-use: 0.1.0-alpha1
  • System Node after update: v24.15.0
  • node_repl.exe: app-packaged binary

Investigation

There were two separate problems.

  1. Initially, node_repl resolved old system Node:
Node runtime too old for node_repl (resolved C:\Program Files\nodejs\node.exe): found v22.14.0, requires >= v22.22.0

Updating system Node to v24.15.0 fixed node_repl startup.

  1. After Node was fixed, external navigation still failed with:
failed to start codex app-server: The system cannot find the path specified. (os error 3)

The desktop process had this path on PATH:

%LOCALAPPDATA%\OpenAI\Codex\bin

But that directory did not exist.

The actual helper binaries existed under the packaged app cache:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin

That directory contained:

codex.exe
node_repl.exe
node.exe
rg.exe
codex-command-runner.exe
codex-windows-sandbox-setup.exe

After mirroring those helper binaries into the expected %LOCALAPPDATA%\OpenAI\Codex\bin path, browser-use external navigation worked.

Verification after workaround

@browser-use successfully:

  1. Bootstrapped with setupAtlasRuntime({ backend: "iab" })
  2. Created/listed an IAB tab
  3. Navigated to https://example.com/
  4. Read the DOM/title
  5. Clicked the single anchor on the page
  6. Navigated to https://www.iana.org/help/example-domains

Expected behavior

Codex Desktop should either:

  • create/populate %LOCALAPPDATA%\OpenAI\Codex\bin, if that path is expected to be on PATH, or
  • put the actual packaged helper bin path on PATH, or
  • have node_repl/nodeRepl.fetch resolve the helper from the packaged app location directly.

browser-use external navigation should not fail with os error 3 when the app-server is already running and the IAB backend is active.

Notes

The issue is easy to miss because local browser navigation works. The failure only appears on external URLs because browser-use performs a remote site-status check through nodeRepl.fetch.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19423
  • #19314
  • #19187
  • #19477
  • #19450

Powered by Codex Action

shikyo13 · 4 months ago

Adding another Windows repro that appears to share the first failure mode in this issue. Details are redacted to avoid user, workspace, and project identifiers.

Environment:

  • OS: Windows x64
  • Codex Desktop package: OpenAI.Codex_26.422.3464.0_x64__2p2nqsd0c76g0
  • Browser Use: 0.1.0-alpha1
  • Workspace/project details: redacted

Observed node_repl failure:

Node runtime too old for node_repl (resolved C:\Program Files\nodejs\node.exe): found v22.16.0, requires >= v22.22.0. Install/update Node or set NODE_REPL_NODE_PATH to a newer runtime.

Local runtime checks:

C:\Program Files\nodejs\node.exe
-> v22.16.0

C:\Program Files\WindowsApps\OpenAI.Codex_26.422.3464.0_x64__2p2nqsd0c76g0\app\resources\node.exe
-> direct execution fails with Access is denied

%USERPROFILE%\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe
-> v24.14.0

Configuration attempted:

  • NODE_REPL_NODE_PATH set in %USERPROFILE%\.codex\config.toml
  • NODE_REPL_NODE_PATH also set in User environment
  • [shell_environment_policy] inherit = "all"
  • Required Windows vars verified present in config and User environment: APPDATA, LOCALAPPDATA, LOCALLOWAPPDATA, USERPROFILE, HOME, HOMEDRIVE, HOMEPATH, ProgramData, TEMP, TMP, SystemRoot, WINDIR, ComSpec

After restarting Codex Desktop, node_repl still resolves the old system Node at C:\Program Files\nodejs\node.exe instead of honoring NODE_REPL_NODE_PATH or using the working per-user Codex runtime.

Difference from #19271:

  • The active node_repl failure here is not Access is denied; it is old system Node selection.
  • Access is denied only appears when directly testing the WindowsApps packaged Node.

Expected behavior:

  • node_repl should honor NODE_REPL_NODE_PATH, or prefer the working per-user Codex runtime when available.
  • If NODE_REPL_NODE_PATH is not intended to control this runtime, the error or docs should say what controls node_repl runtime selection on Windows.
firstunicorn · 4 months ago

Have same issue

Margeshy · 4 months ago

I’m seeing the same issue today on Windows with Codex Desktop.

Environment observed locally:

  • Codex Desktop package: OpenAI.Codex_26.422.3464.0_x64__2p2nqsd0c76g0
  • Codex CLI: codex-cli 0.125.0
  • Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha1
  • In-app browser current tab: about:blank

What works:

  • Browser Use can bootstrap the IAB backend after the in-app browser is open.
  • agent.browser.tabs.selected() succeeds.
  • The selected tab is visible and reports about:blank.

What fails:

  • Navigating to an external URL, e.g. https://haraj.com.sa/search/7700%20xt/
  • The failure occurs before navigation completes.

Error:

failed to start codex app-server: The system cannot find the path specified. (os error 3)

Local checks:

  • %LOCALAPPDATA%\OpenAI\Codex\bin exists and contains codex.exe, node.exe, node_repl.exe, rg.exe, codex-command-runner.exe, and codex-windows-sandbox-setup.exe.
  • The packaged cache path also exists:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin

  • Browser Use plugin file exists:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\browser-use\0.1.0-alpha1\scripts\browser-client.mjs

This looks like the same external-navigation/app-server helper path failure described here. The browser bridge can attach to the IAB tab, but external URL navigation triggers the app-server path error.

ahostbr · 3 months ago

Confirmed local Windows Codex Desktop workaround for this issue.

On this machine, the helper binaries already existed at:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin

but the expected path:

%LOCALAPPDATA%\OpenAI\Codex\bin

was missing.

Creating a directory junction from the expected path to the existing helper-bin path fixed Browser Use / in-app browser control here.

PowerShell workaround:

$target = "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin"
$link = "$env:LOCALAPPDATA\OpenAI\Codex\bin"

New-Item -ItemType Directory -Force -Path (Split-Path $link) | Out-Null
New-Item -ItemType Junction -Path $link -Target $target

After adding the junction and retrying in Codex Desktop, Browser Use was able to:

This suggests Desktop expects %LOCALAPPDATA%\OpenAI\Codex\bin to exist, but it is not always being created or refreshed. Product-side fix should likely ensure that path is populated automatically, or resolve helper binaries directly from the existing package-cache helper path instead of requiring a manual junction.

shikyo13 · 3 months ago

⚠️ Something went wrong while processing your request. Please try again, or
use /new to start a fresh session.
On Thu, Apr 30, 2026, 6:30 PM CDT, ahostbr wrote:

ahostbr left a comment (openai/codex#19562) <https://github.com/openai/codex/issues/19562#issuecomment-4356858649> Confirmed local Windows Codex Desktop workaround for this issue. On this machine, the helper binaries already existed at: %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin but the expected path: %LOCALAPPDATA%\OpenAI\Codex\bin was missing. Creating a directory junction from the expected path to the existing helper-bin path fixed Browser Use / in-app browser control here. PowerShell workaround: $target = "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin" $link = "$env:LOCALAPPDATA\OpenAI\Codex\bin" New-Item -ItemType Directory -Force -Path (Split-Path $link) | Out-Null New-Item -ItemType Junction -Path $link -Target $target After adding the junction and retrying in Codex Desktop, Browser Use was able to: - attach to the selected in-app browser tab - navigate to https://example.com/ - read DOM snapshots - click the page link - navigate to https://www.iana.org/help/example-domains This suggests Desktop expects %LOCALAPPDATA%\OpenAI\Codex\bin to exist, but it is not always being created or refreshed. Product-side fix should likely ensure that path is populated automatically, or resolve helper binaries directly from the existing package-cache helper path instead of requiring a manual junction. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/19562#issuecomment-4356858649>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQS6SMNMTGB6PBNUZVLXF34YPOZHAVCNFSM6AAAAACYGGMIA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNJWHA2TQNRUHE> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: @.***>
zemeng5208 · 16 days ago

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

This issue is directly within the runtime-consistency layer the project targets. The confirmed workaround here shows two local causes that can coexist: node_repl resolving the wrong/too-old Node runtime, and the Desktop process expecting %LOCALAPPDATA%\OpenAI\Codex\bin even when the actual helper binaries only exist under the packaged LocalCache path. Once the expected helper path was restored, Browser external navigation worked again.

WinBridge v3.1.1 checks the current installed package/runtime, NODE_REPL_NODE_PATH, CODEX_CLI_PATH, Node REPL command paths, version/hash directories and user-side helper/bin state together instead of assuming one path is authoritative. When the official resources exist but the user-owned runtime path is missing/stale, it can reconstruct the local mirror through verified staging and SHA-256 checks with rollback data.

It should not override a healthy user runtime with a worse system Node, and it does not modify WindowsApps. If all helper/runtime paths are valid and external navigation still fails in the Browser protocol layer, that remaining failure is upstream rather than something WinBridge should force around.