Skip to content

Browser Use / in-app browser fails to navigate to any external URL. #19477

Closed as duplicate

Description

@DFColumbus

What version of the Codex App are you using (From “About Codex” dialog)?

26.422.3464.0

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When asking codex to use in-app browser it fails.

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

What steps can reproduce the bug?

Repro:

  1. Open Codex Desktop on Windows.
  2. Open the in-app browser.
  3. Ask Codex to open https://example.com or https://www.integrationatlas.com/
  4. Browser does not navigate.

What is the expected behavior?

No response

Additional information

Notes:

  • Browser Use plugin is installed and loads.
  • The failure happens before navigation.
  • nodeRepl.fetch also fails with the same app-server error.
  • Local inspection showed multiple Codex WindowsApps package versions installed, and running Codex processes appeared to reference the older package path.

Activity

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

    @neusse

    I was able to identify the issue and I have a work around explained at...

    #19423 (comment)

  4. ahostbr commented on May 2, 2026

    @ahostbr

    Cross-linking a local workaround that fixed this same Windows Codex Desktop / Browser Use failed to start codex app-server: ... (os error 3) failure here: #19562 (comment)

    On my machine, %LOCALAPPDATA%\OpenAI\Codex\bin was expected/on the Desktop path but missing. The helper binaries already existed at:

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

    Creating a junction from the expected path to the packaged helper-bin path fixed Browser Use / in-app browser control:

    $target = "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin"
    $link = "$env:LOCALAPPDATA\OpenAI\Codex\bin"
    
    if (!(Test-Path $target)) { throw "Target not found: $target" }
    
    New-Item -ItemType Directory -Force -Path (Split-Path $link) | Out-Null
    if (!(Test-Path $link)) {
        New-Item -ItemType Junction -Path $link -Target $target
    }

    After adding the junction and retrying in Codex Desktop, Browser Use could attach to the selected in-app browser tab, navigate to external pages, read DOM snapshots, click links, and continue navigating.

    This may not cover every Windows Browser Use failure, but it looks relevant when the IAB backend can initialize/list tabs and then navigation/DOM/screenshot work fails with failed to start codex app-server: ... (os error 3).

  5. zemeng5208 commented on Aug 12, 2026

    @zemeng5208

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

    The detail here that multiple AppX package versions were installed and running Codex processes appeared to reference an older package path is exactly the kind of update split-brain WinBridge checks. v3.1.1 resolves the current Store package first, then validates generated CLI/Node REPL/app-server paths, version/hash directories and user-owned runtime state against that package instead of trusting stale process/config paths.

    The confirmed workaround linked later in this thread — restoring the expected %LOCALAPPDATA%\OpenAI\Codex\bin path when the helper binaries existed elsewhere in the packaged LocalCache — is within the same recovery class. WinBridge can reconstruct the current user-side helper/runtime state through verified staging and SHA-256 checks with backups/rollback, without pointing the long-term runtime directly at an obsolete AppX version.

    If all effective runtime/app-server paths are current and Browser still fails in the protocol/preflight layer, that remaining issue is upstream. It does not modify WindowsApps ownership/ACLs or bypass Browser policy.

  6. etraut-openai commented on Oct 13, 2026

    @etraut-openai
    Contributor

    (response from codex)

    Thanks for the report. Closing in favor of #19187, which tracks this Windows Browser Use / nodeRepl.fetch failure to start the app-server for external navigation. The multiple WindowsApps versions and stale process paths you observed are useful context for that tracker; we are not treating a local workaround as a product fix.

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