Skip to content

Windows 11 Codex Desktop: Browser Use works on localhost but fails for external URLs with “failed to start codex app-server” #20872

Closed as duplicate

Description

@ath

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\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?

  1. Use Codex Desktop on Windows 11 Pro.

  2. Open Browser Use in the in-app browser.

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

  4. Ask Codex Browser Use to open http://127.0.0.1:3000/.

  5. Observe that Browser Use can open the localhost page, find the button, click it, and verify the changed text.

  6. Then ask Codex Browser Use to open an external URL, for example https://example.com/.

  7. Observe that Browser Use fails with:

failed to start codex app-server: Das System kann den angegebenen Pfad nicht finden. (os error 3)

  1. Repeat with another external URL, for example https://www.heise.de/newsticker/. The same error occurs.

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

  1. Check command resolution with:

where.exe codex

This resolves only to the WindowsApps package paths.

  1. Try changing the user PATH so that:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin

appears before WindowsApps, then restart Codex and reboot Windows.

  1. 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:

#13542

#13965

#15179

#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

Activity

  1. added
    appIssues related to the Codex desktop app
    on May 3, 2026
  2. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    on May 3, 2026
  3. ath commented on May 4, 2026

    @ath
    Author

    I think #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.

  4. zemeng5208 commented on Aug 12, 2026

    @zemeng5208

    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 from WindowsApps.

    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.

  5. etraut-openai commented on Oct 13, 2026

    @etraut-openai
    Contributor

    (response from codex)

    Thanks for isolating localhost versus external URLs. Closing as a duplicate of #19187, which tracks Windows external Browser Use calls failing to start the helper app-server even while the browser is otherwise connected. Your successful localhost automation and failed PATH/reinstall attempts help narrow that issue. No fix is being claimed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions