You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Browser Use / in-app browser fails to navigate to any external URL. #19477
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.
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:
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).
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.
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.
Activity
neusse commentedon Apr 25, 2026
I was able to identify the issue and I have a work around explained at...
#19423 (comment)
ahostbr commentedon May 2, 2026
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\binwas expected/on the Desktop path but missing. The helper binaries already existed at:%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\binCreating a junction from the expected path to the packaged helper-bin path fixed Browser Use / in-app browser control:
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 commentedon Aug 12, 2026
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\binpath 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.
etraut-openai commentedon Oct 13, 2026
(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.