Skip to content

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

Open
Open
Windows Codex Desktop Browser Use fails to start app-server despite working npm CLI#20048
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

Description

@mmgh993-hue
mmgh993-hue
opened on Apr 28, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.422.8496.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 10 Home, 64-bit, build 26100

What issue are you seeing?

Codex Desktop Browser Use does not work on Windows.

When I use the Browser Use plugin, it only sees an about:blank tab and cannot navigate or inspect the in-app browser. Attempting to navigate with Browser Use fails with:

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

Inside Codex, Browser Use returns:

agent.browser.tabs.list() => about:blank
agent.browser.user.openTabs() => []

A simple test like navigating to https://example.com fails with the same app-server error.

I also tested the packaged Codex executable directly in PowerShell:

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

That fails with:

Access is denied

I installed the standalone npm CLI:

npm.cmd install -g @openai/codex

Then:

codex.cmd app-server --help

works correctly and prints the app-server help text.

So the standalone CLI appears healthy, but Codex Desktop Browser Use still fails, likely because it is trying to start the packaged WindowsApps codex.exe or otherwise not resolving the working codex.cmd from PATH.

I already tried:

  • Restarting Windows
  • Terminating Codex
  • Repairing Codex from Windows Apps settings
  • Resetting Codex
  • Uninstalling/reinstalling Codex Desktop
  • Fully quitting/reopening Codex Desktop
  • Installing the npm CLI

The issue still persists.

What steps can reproduce the bug?

  1. Install and open Codex Desktop on Windows.
  2. Open a Codex thread with the Browser Use plugin enabled.
  3. Ask Codex to use Browser Use or run a basic Browser Use navigation test.
  4. Browser Use initializes but only sees an about:blank tab.
  5. Attempt to navigate the Browser Use tab to a simple site such as https://example.com.
  6. The navigation fails with:

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

Additional reproduction/check:

  1. In PowerShell, run the packaged Codex executable directly:

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

  1. It fails with:

Access is denied

  1. Install standalone CLI:

npm.cmd install -g @openai/codex

  1. Run:

codex.cmd app-server --help

  1. This works, but Browser Use in Codex Desktop still fails with the same app-server error.

What is the expected behavior?

Browser Use should start or connect to a working Codex app-server, attach to the in-app browser tab, and allow normal browser automation actions such as navigation, screenshots, DOM snapshots, clicks, and form interactions.

For example, navigating to https://example.com through Browser Use should load the page and allow DOM/screenshot inspection instead of failing with an app-server path error.

Additional information

Additional context: I am logged into GitHub with a different account than my ChatGPT/Codex account. I do not know if this is related, but I wanted to mention it. The Browser Use failure appears to happen before any GitHub-specific action, during Codex app-server startup/navigation. m_m_gh@windowslive.com is my account for codex

Activity

  1. mmgh993-hue
    added
    appIssues related to the Codex desktop app
    on Apr 28, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    on Apr 28, 2026

  3. mmgh993-hue commented on Apr 28, 2026

    @mmgh993-hue
    mmgh993-hue
    on Apr 28, 2026
    Author

    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.

  4. github-actions commented on Apr 28, 2026

    @github-actions
    github-actionsbot
    on Apr 28, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  5. neusse commented on Apr 28, 2026

    @neusse
    neusse
    on Apr 28, 2026

    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.

  6. RihanSchalkwyk commented on Apr 28, 2026

    @RihanSchalkwyk
    RihanSchalkwyk
    on Apr 28, 2026 – with ChatGPT Codex Connector

    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.

  7. Dimava commented on Apr 29, 2026

    @Dimava
    Dimava
    on Apr 29, 2026

    Work Around bellow.

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

  8. LeizhenZhang commented on May 2, 2026

    @LeizhenZhang
    LeizhenZhang
    on May 2, 2026

    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.

  9. Ryan-M86 commented on May 2, 2026

    @Ryan-M86
    Ryan-M86
    on May 2, 2026

    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.

  10. LeizhenZhang commented on May 2, 2026

    @LeizhenZhang
    LeizhenZhang
    on May 2, 2026 via email

  11. ahostbr commented on May 2, 2026

    @ahostbr
    ahostbr
    on 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\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).

  12. etraut-openai
    added
    browser
    on May 3, 2026

  13. zemeng5208 commented on Aug 12, 2026

    @zemeng5208
    zemeng5208
    on Aug 12, 2026 – with ChatGPT Codex Connector

    I maintain WinBridge Recovery for Windows Codex Desktop local runtime recovery: https://github.com/zemeng5208/winbridge-recovery

    The confirmed workaround in this thread is almost exactly the failure pattern the project now checks: Desktop expects a user-local runtime containing both node_repl.exe and its companion codex.exe, but that runtime path is missing/stale while the official packaged copies exist. Recreating only node_repl.exe changes the error from path-not-found to file-not-found; adding the companion codex.exe restores nodeRepl.fetch and Browser navigation. That is strong evidence of a materialization/path-consistency bug rather than a generic account or site issue.

    WinBridge v3.1.1 detects the current AppX package, verifies official CLI/CUA resources, builds a user-owned verified resource mirror, and validates the effective Node REPL/CODEX_CLI_PATH/app-server paths before switching anything. It is intended to recover this state without requiring users to delete all Codex setup or manually copy binaries into guessed paths after every update.

    It does not modify WindowsApps ownership/ACLs or substitute a third-party CLI for the trusted Desktop bridge. If the current user runtime is complete and the remaining failure is upstream Browser/tool injection, it stops at diagnosis.

  14. arphox commented on Sep 22, 2026

    @arphox
    arphox
    on Sep 22, 2026

    I also experience this issue, and this with MANY other issues are basically messing up my ChatGPT Codex local Windows workflow. Please start fixing these bugs.

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