Skip to content

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

Open
Open
Windows browser-use external navigation fails when Codex helper bin path is missing#19562
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@michaelbuckner
michaelbuckner
opened on Apr 25, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    on Apr 25, 2026

  2. github-actions commented on Apr 25, 2026

    @github-actions
    github-actionsbot
    on Apr 25, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. shikyo13 commented on Apr 25, 2026

    @shikyo13
    shikyo13
    on Apr 25, 2026 – with ChatGPT Codex Connector

    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.

  4. firstunicorn commented on Apr 25, 2026

    @firstunicorn
    firstunicorn
    on Apr 25, 2026

    Have same issue

  5. Margeshy commented on Apr 26, 2026

    @Margeshy
    Margeshy
    on Apr 26, 2026 – with ChatGPT Codex Connector

    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.

  6. ahostbr commented on Apr 30, 2026

    @ahostbr
    ahostbr
    on Apr 30, 2026

    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.

  7. shikyo13 commented on Apr 30, 2026

    @shikyo13
    shikyo13
    on Apr 30, 2026 via email
  8. etraut-openai
    added
    browser
    on May 3, 2026

  9. zemeng5208 commented on Aug 12, 2026

    @zemeng5208
    zemeng5208
    on Aug 12, 2026 – with ChatGPT Codex Connector

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions