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
Windows: browser-use IAB can initialize and list tabs, but tab.goto() fails with failed to start codex app-server: 系统找不到指定的路径 (os error 3) #20130
After copying those files and restarting Codex, Browser Use / in-app browser started working again.
This looks like a Windows packaging/cache/runtime path issue: Browser Use expects the local Codex runtime under %LOCALAPPDATA%\OpenAI\Codex\bin, but the files may only exist under the MSIX LocalCache or installation resources path.
This issue is a direct match for the user-side helper materialization layer the project targets. The workaround reported here is especially useful evidence: the IAB backend can initialize and list tabs, but %LOCALAPPDATA%\OpenAI\Codex\bin is missing/incomplete; once the expected Codex helper runtime is restored, Browser Use navigation works again.
WinBridge v3.1.1 resolves the currently installed Microsoft Store AppX first, verifies the official bundled CLI/CUA resources, and checks the effective user-side codex.exe, node.exe, node_repl.exe, rg.exe, CODEX_CLI_PATH, NODE_REPL_NODE_PATH, and app-server/runtime paths together. When the official source is present but the user-owned runtime is missing or stale, it can rebuild that local state through verified staging, source/destination SHA-256 checks, backups, and rollback rather than requiring users to manually copy a guessed set of binaries after every update.
It does not modify WindowsApps ownership/ACLs or patch the Store package. If the user-side helper/runtime state is already complete and current but Browser operations still fail, that remaining layer should be treated as an upstream Browser/app-server issue rather than something WinBridge should force around.
Thanks for the reproduction and follow-up. Closing as a duplicate of #19187. It tracks the same Windows Browser Use failure after successful tab initialization, with external navigation unable to start codex app-server (os error 3). Your helper-path findings match one variant covered there.
Activity
github-actions commentedon Apr 29, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
jay52121 commentedon Apr 29, 2026
I found a working workaround for Windows Codex App Browser Use failing with:
failed to start codex app-server
The system cannot find the path specified. (os error 3)
In my case, Codex Browser Use was looking for runtime files under:
%LOCALAPPDATA%\OpenAI\Codex\bin
But that directory was missing or incomplete.
Workaround:
%LOCALAPPDATA%\OpenAI\Codex\bin
%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin
to:
%LOCALAPPDATA%\OpenAI\Codex\bin
C:\Program Files\WindowsApps\OpenAI.Codex_\app\resources
After copying those files and restarting Codex, Browser Use / in-app browser started working again.
This looks like a Windows packaging/cache/runtime path issue: Browser Use expects the local Codex runtime under %LOCALAPPDATA%\OpenAI\Codex\bin, but the files may only exist under the MSIX LocalCache or installation resources path.
zemeng5208 commentedon Aug 12, 2026
I maintain WinBridge Recovery, an independent Windows Codex Desktop local runtime/plugin recovery tool: https://github.com/zemeng5208/winbridge-recovery
This issue is a direct match for the user-side helper materialization layer the project targets. The workaround reported here is especially useful evidence: the IAB backend can initialize and list tabs, but
%LOCALAPPDATA%\OpenAI\Codex\binis missing/incomplete; once the expected Codex helper runtime is restored, Browser Use navigation works again.WinBridge v3.1.1 resolves the currently installed Microsoft Store AppX first, verifies the official bundled CLI/CUA resources, and checks the effective user-side
codex.exe,node.exe,node_repl.exe,rg.exe,CODEX_CLI_PATH,NODE_REPL_NODE_PATH, and app-server/runtime paths together. When the official source is present but the user-owned runtime is missing or stale, it can rebuild that local state through verified staging, source/destination SHA-256 checks, backups, and rollback rather than requiring users to manually copy a guessed set of binaries after every update.It does not modify WindowsApps ownership/ACLs or patch the Store package. If the user-side helper/runtime state is already complete and current but Browser operations still fail, that remaining layer should be treated as an upstream Browser/app-server issue rather than something WinBridge should force around.
etraut-openai commentedon Oct 13, 2026
(response from codex)
Thanks for the reproduction and follow-up. Closing as a duplicate of #19187. It tracks the same Windows Browser Use failure after successful tab initialization, with external navigation unable to start codex app-server (os error 3). Your helper-path findings match one variant covered there.