Browser Use / in-app browser fails to start app-server on Windows 10 (os error 3)

keeps failing even with latest update of today

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

Codex Desktop Windows 26.429.3425.0

Browser Use / in-app browser cannot open google.com.

Initial failure:
failed to execute Node: Access is denied. (os error 5)

Confirmed:
C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\resources\node.exe
→ Access is denied

C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\resources\rg.exe
→ Access is denied

Confirmed working:
C:\Users\mmggr\.cache\codex-runtimes\codex-primary-runtime\dependencies\node\bin\node.exe
→ v24.14.0

Workaround tried:
Copied the working node.exe into recent:
C:\Users\mmggr\.codex\tmp\...\codex-arg*

Result:
node_repl minimal calls started working and Browser Use could detect an about:blank tab.

New failure:
Trying to open https://www.google.com causes node_repl/kernel to close and Codex falls back to:
windows sandbox failed: runner error: CreateProcessAsUserW failed: 5

Also tried:
[windows]
sandbox = "unelevated"

Result:
Does not fix Browser Use. node_repl / Browser Use still fail.

Tried enabling runCodexInWindowsSubsystemForLinux manually in:
C:\Users\mmggr\.codex\.codex-global-state.json

Result:
Codex hangs indefinitely when running pwd, so WSL agent mode is not usable from this build/UI.

Conclusion:
This appears to combine the WindowsApps packaged helper execution failure with the Windows sandbox CreateProcessAsUserW failed: 5 issue. Browser Use remains unusable on this Windows Desktop build.

Bump! Any progress?

Yeah, if you go with the method I posted, put an agent at it, it should fix it.
It's basically creating a shim that targets the correct path.

<img width="3248" height="1281" alt="Image" src="https://github.com/user-attachments/assets/976a585a-514e-4d89-98bd-c06dfe8b53c1" />

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

This issue now contains two distinct Windows failures, and WinBridge only targets the first one. The confirmed os error 3/helper-path variant — where the expected %LOCALAPPDATA%\OpenAI\Codex\bin path is missing or stale while usable helper binaries exist elsewhere — is within its scope. v3.1.1 resolves the current official package/runtime, validates CLI/Node REPL/helper paths and can reconstruct inconsistent user-owned runtime state through staged, hash-verified copies with rollback data.

The later CreateProcessAsUserW failed: 5 Windows sandbox failure is a separate upstream sandbox/security-token layer. If the helper/runtime paths are repaired and Browser then fails only in sandbox process creation, WinBridge should not claim to fix or bypass that failure.

So the tool can help recover and clearly classify the initial local runtime-path problem without turning a sandbox failure into another unsafe workaround. It does not change WindowsApps ACLs/ownership, sandbox policy, or package contents.