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

Open 💬 3 comments Opened Apr 25, 2026 by 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:

Open Codex Desktop on Windows.
Open the in-app browser.
Ask Codex to open https://example.com or https://www.integrationatlas.com/
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.

View original on GitHub ↗

3 Comments

neusse · 4 months ago

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

https://github.com/openai/codex/issues/19423#issuecomment-4317666215

ahostbr · 3 months ago

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: https://github.com/openai/codex/issues/19562#issuecomment-4356858649

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).

zemeng5208 · 16 days ago

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.