Windows Codex Desktop Browser Use fails to start app-server despite working npm CLI

Additional confirmation: after installing the standalone CLI with npm, codex.cmd app-server --help works successfully, but Browser Use in Codex Desktop still fails with the app-server error. This suggests the Desktop Browser Use bridge is not using the working npm CLI or is still trying to launch the packaged WindowsApps codex.exe.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #19562
• #19423
• #19314
• #19450
• #19187

Powered by Codex Action

Work Around bellow. I also uninstalled and "DELETED" everything codex related and did a clean install. Everything works fine after clean install. But a clean install is painful if you have a lot of setup done.

Workaround:

I manually recreated the missing local directory and copied node_repl.exe from the packaged app resources into the stale AppData path. That changed the failure from:

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

to:

failed to start codex app-server: The system cannot find the file specified. (os error 2)

Searching strings in node_repl.exe showed it starts:

codex app-server --listen stdio://

So I also copied the packaged codex.exe into the same AppData bin directory:

C:\Users\georg\AppData\Local\OpenAI\Codex\bin\codex.exe

After that, the authenticated fetch bridge started working. This call succeeded:

nodeRepl.fetch("https://chatgpt.com/backend-api/aura/site_status?site_url=https%3A%2F%2Fwww.fox.com")

Response:

{
  "feature_status": {
    "user_site_settings_toggle": false,
    "agent": false,
    "side_chat": false,
    "cursor_chat": false,
    "page_view": false,
    "page_content": false,
    "analytics": false
  },
  "debug_reason": null,
  "enabled": true
}

Browser Use then no longer failed with the app-server error. Programmatic navigation to https://www.fox.com/home reached the page, and DOM access worked afterward.

This seems to confirm that the bug is Codex Desktop launching node_repl.exe from a stale/missing user-local binary path, and that node_repl.exe expects a companion codex.exe beside it for codex app-server. The fix likely needs to ensure the AppData bin cache is created/refreshed correctly, or that Desktop launches the packaged resource binaries directly.

I can confirm the packaged WindowsApps executable failure on another Windows install with the same Codex Desktop package version.

Environment:

OpenAI.Codex 26.422.8496.0
InstallLocation: C:\Program Files\WindowsApps\OpenAI.Codex_26.422.8496.0_x64__2p2nqsd0c76g0
Platform: Windows x64
Workspace involved: WSL UNC path under \\wsl.localhost\Ubuntu\home\<user>\Projects\...

User-visible symptom:

• Codex Desktop briefly shows the login screen, appears to authenticate, then gets stuck indefinitely on the app loading screen with the Codex icon.
• This happens before the app becomes usable, so it presents as a startup/load hang rather than only a Browser Use failure.

Direct packaged executable check:

& "C:\Program Files\WindowsApps\OpenAI.Codex_26.422.8496.0_x64__2p2nqsd0c76g0\app\resources\codex.exe" --help

fails with:

Program 'codex.exe' failed to run: Access is denied
CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
FullyQualifiedErrorId : NativeCommandFailed

Sandbox diagnostics also show the WindowsApps ACL/setup failure family:

grant read ACE failed on C:\Program Files\WindowsApps\OpenAI.Codex_26.304.1528.0_x64__2p2nqsd0c76g0\app\resources for sandbox_group: SetNamedSecurityInfoW failed: 5
read ACL run completed with errors
setup error: read ACL run had errors

and later setup refresh failures against the WSL workspace and temp path:

write ACE failed on \\?\UNC\wsl.localhost\Ubuntu\home\<user>\Projects\...: GetSecurityInfo failed ...: 1
write ACE failed on C:\Users\<user>\AppData\Local\Temp: SetNamedSecurityInfoW failed: 5
deny ACE failed on \\wsl.localhost\Ubuntu\home\<user>\Projects\...\.codex: GetNamedSecurityInfoW failed: 1
setup error: setup refresh had errors

%USERPROFILE%\.codex\.sandbox\setup_error.json contains:

{
  "code": "helper_unknown_error",
  "message": "setup refresh had errors"
}

This looks like the same underlying issue: the Desktop app can authenticate and render initial UI, but startup/runner initialization fails when it needs the packaged codex.exe / sandbox setup path. The WSL UNC workspace may be an additional trigger, but the direct codex.exe --help access-denied repro seems independent of Browser Use.

Work Around bellow.

Thanks for the workaround, I've linked this thread and Codex fixed everything itself

I can also reproduce this issue on Windows Codex Desktop.

My case is very similar, with one additional data point: the manual app-server startup works, not just --help.

Environment:

• OS: Windows
• Codex Desktop / Windows app
• codex-cli: 0.128.0-alpha.1
• Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha1

What works:

• Browser-in-app initializes.
• It sees an about:blank tab.
• DOM snapshot on about:blank succeeds.
• Browser Use is enabled.
• Approval and History are set to Always allow.
• No blocked domains are configured.
• The plugin script exists:

C:\Users\zhang\.codex\plugins\cache\openai-bundled\browser-use\0.1.0-alpha1\scripts\browser-client.mjs

• Manual app-server startup works:

codex app-server --listen ws://127.0.0.1:0

It starts successfully, for example on:

ws://127.0.0.1:60095

• Health checks succeed:

curl.exe -i http://127.0.0.1:60095/healthz
curl.exe -i http://127.0.0.1:60095/readyz

Both return:

HTTP/1.1 200 OK
content-length: 0

What fails:

• Browser-in-app cannot navigate to external websites.
• Navigating to https://example.com/ fails.
• Navigating to https://www.baidu.com/ also fails.
• Error:

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

So in my case the app-server can run manually, but the Browser Use / in-app browser integration still fails to auto-start or bind to it when navigating to an external URL.

Having the same issue:

Codex desktop Browser Use runtime issue

Date: 2026-05-02
OS: Windows
In-app browser state: open, not currently navigated

What I tried:
Codex attempted to initialise Browser Use / in-app browser automation using the Browser Use skill and Node REPL bridge.

Result:
The Node REPL tool was discovered, but Browser Use failed before navigation.

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

Expected:
Browser Use should start the Codex app-server/runtime and allow Codex to open or inspect the in-app browser tab.

Impact:
The visible in-app browser can be opened manually, but Codex cannot automate or verify pages through Browser Use.

  您好，您的邮件我已收到，我会及时处理的！谢谢！

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