Windows 11 Codex Desktop: Browser Use works on localhost but fails for external URLs with “failed to start codex app-server”
What version of the Codex App are you using (From “About Codex” dialog)?
26.429.30905
What subscription do you have?
Pro (ca 100€ per month)
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Browser Use in Codex Desktop works for localhost pages but fails for external websites on my Windows 11 Pro laptop.
I tested Browser Use with a small local Node.js app on
http://127.0.0.1:3000/
Codex Browser Use could open the local page, inspect it, find a button, click it, and verify that the page text changed after the click.
However, when I try external URLs such as
https://example.com/
or
https://www.heise.de/newsticker/
, Browser Use fails before it can navigate, inspect the DOM, take a screenshot, or click anything.
The error shown by Codex is:
failed to start codex app-server: Das System kann den angegebenen Pfad nicht finden. (os error 3)
This seems specific to external URLs. Localhost Browser Use works.
I also noticed WindowsApps/MSIX path behavior that may be related. Get-Command codex -All shows both the user-local Codex binary and the WindowsApps package binary, but where.exe codex resolves only to the WindowsApps package paths. Codex commands also print:
WARNING: proceeding, even though we could not update PATH: Zugriff verweigert (os error 5)
I changed my user PATH so that C:\Users<user>\AppData\Local\OpenAI\Codex\bin appears before WindowsApps, restarted Codex, rebooted Windows, uninstalled Codex, and reinstalled it using the installer downloaded from OpenAI. The problem remained.
What steps can reproduce the bug?
- Use Codex Desktop on Windows 11 Pro.
- Open Browser Use in the in-app browser.
- Create and start a minimal local test server on port 3000, for example a Node.js server serving a simple HTML page with a button and a status text.
- Ask Codex Browser Use to open
http://127.0.0.1:3000/.
- Observe that Browser Use can open the localhost page, find the button, click it, and verify the changed text.
- Then ask Codex Browser Use to open an external URL, for example
https://example.com/.
- Observe that Browser Use fails with:
failed to start codex app-server: Das System kann den angegebenen Pfad nicht finden. (os error 3)
- Repeat with another external URL, for example
https://www.heise.de/newsticker/. The same error occurs.
- Check command resolution with:
Get-Command codex -All
This shows both:
C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\codex.exe
and:
C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\codex.exe
- Check command resolution with:
where.exe codex
This resolves only to the WindowsApps package paths.
- Try changing the user PATH so that:
C:\Users\<user>\AppData\Local\OpenAI\Codex\bin
appears before WindowsApps, then restart Codex and reboot Windows.
- The issue still reproduces.
What is the expected behavior?
Browser Use should be able to open and interact with external websites, subject to the normal Browser Use safety checks and user permissions, just as it can interact with localhost pages.
External URLs such as https://example.com/ should not fail with a local codex app-server path error.
Additional information
This may be related to existing Windows/MSIX/WindowsApps path or ACL issues in Codex Desktop:
https://github.com/openai/codex/issues/13542
https://github.com/openai/codex/issues/13965
https://github.com/openai/codex/issues/15179
https://github.com/openai/codex/issues/17901
I could not find an existing issue with this exact Browser Use reproduction:
- localhost Browser Use works
- external URL Browser Use fails
- the failure is:
failed to start codex app-server: Das System kann den angegebenen Pfad nicht finden. (os error 3)
Environment details from my testing:
- Windows 11 Pro laptop
- Codex Desktop installed via Microsoft Store/MSIX path
- Codex CLI reported inside the Codex Desktop shell:
codex-cli 0.128.0-alpha.1
Inside the Codex Desktop shell, Get-Command codex -All showed a user-local Codex path:
C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\codex.exe
and also the WindowsApps package path:
C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\codex.exe
However, the user-local path appears to exist only inside the Codex Desktop shell/sandbox. It does not exist in my normal Windows Explorer or normal PowerShell.
In my normal PowerShell 7.6.1, codex-cli, codex, and where.exe codex all fail because no executable is found.
Observed WindowsApps path:
C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I think https://github.com/openai/codex/issues/19314 is about the same. I suggest though to use the context from this one as well, as I gave some more steps to reproduce and some background information.
I maintain WinBridge Recovery, an independent Windows Codex Desktop local runtime/plugin recovery tool: https://github.com/zemeng5208/winbridge-recovery
The localhost-vs-external split in this report is a useful diagnostic signal. If Browser Use can fully inspect/click a localhost page but external navigation fails only when the authenticated
nodeRepl.fetch/ app-server path is needed, the IAB/browser backend itself is not necessarily the broken layer. The Windows helper/CLI path used by that deeper operation is worth validating separately.WinBridge v3.1.1 resolves the currently installed Store AppX, verifies the official CLI/CUA resources, and checks the effective user-side
codex.exe,node_repl.exe,NODE_REPL_NODE_PATH,CODEX_CLI_PATH, version/hash directories and app-server-related paths together. It can rebuild missing/stale user-owned runtime state through verified staging and SHA-256 checks rather than relying on direct execution fromWindowsApps.This is especially relevant to the state described here where command resolution exposes both user-local and package paths but the Desktop/Browser bridge still appears to select an unusable or missing helper path.
It is not a policy bypass: if those local paths are healthy and the external request is actually denied by Browser policy or an upstream app-server/protocol bug, WinBridge should report that boundary and stop. It does not modify WindowsApps ownership/ACLs or patch the Store package.