›_ Codex Issues
Codex Issues / #20354

Windows Codex Desktop Browser Use fails to start app-server for DOM/screenshot on in-app browser

Open 💬 3 comments Opened Apr 30, 2026 by EtienneLescot
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows Codex Desktop, the bundled Browser Use plugin can attach to the in-app browser enough to read basic tab metadata such as title and URL, but DOM/screenshot/CUA operations fail with:

failed to start codex app-server: Le chemin d’accès spécifié est introuvable. (os error 3)

This prevents Browser Use from inspecting or automating the current in-app browser tab.

Environment

  • OS: Windows
  • Codex Desktop package after reinstall: OpenAI.Codex_26.422.9565.0_x64__2p2nqsd0c76g0
  • Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha1
  • In-app browser target tested: Google Photos, e.g. https://photos.google.com/u/0/albums?hl=fr&pli=1
  • Shell: PowerShell

Reproduction

Using the Browser Use skill setup in the Node REPL:

const { setupAtlasRuntime } = await import('C:/Users/etien/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha1/scripts/browser-client.mjs');
await setupAtlasRuntime({ globals: globalThis, backend: 'iab' });

Basic tab metadata works, for example title/URL can be read. But calls such as:

await tab.playwright.domSnapshot()
await tab.playwright.screenshot(...)

fail with:

failed to start codex app-server: Le chemin d’accès spécifié est introuvable. (os error 3)

CUA screenshot/click/scroll operations fail similarly.

Diagnostics already tried

  • Reinstalled Browser Use plugin.
  • Added Microsoft Defender exclusion for:

C:\Users\etien\.codex\plugins\cache\openai-bundled\browser-use

  • Restarted Codex Desktop.
  • Ran Codex Desktop as administrator.
  • Ran codex login; login succeeded.
  • Uninstalled/reinstalled Codex Desktop.
  • Verified Browser Use plugin files exist and browser-client.mjs is readable.
  • Verified app logs changed from ChatGPT account ID not available, please re-run codex login to successful app/list after login.
  • Verified named pipes exist, including:
  • codex-ipc
  • codex-browser-use\31c04a4e-6a05-42ee-a901-2b9ee0de4d7a
  • Get-Command codex resolved to WindowsApps path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.422.9565.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

  • Directly running that WindowsApps codex.exe failed with access/EPERM.
  • User-local binary works:

C:\Users\etien\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\OpenAI\Codex\bin\codex.exe

  • Creating a shim earlier in PATH for codex.cmd/codex.exe pointing to the user-local binary made this work from PowerShell and from Node:
codex app-server --help

and via Node execFile('codex', ['app-server','--help']), but Browser Use DOM/screenshot still failed with the same os error 3.

Expected behavior

Browser Use should be able to start or reach the required Codex app-server and return DOM snapshots/screenshots for the current in-app browser tab.

Actual behavior

Only basic tab metadata works. DOM/screenshot/CUA operations fail because Browser Use cannot start codex app-server, reporting os error 3.

Notes

This looks like a Windows path/process-launch issue inside the Browser Use / app-server startup path rather than a Google Photos-specific problem, because the failure happens before DOM/screenshot data is returned and persists across reinstall, login, admin launch, and Defender exclusion.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #20206
  • #20048
  • #19423
  • #19298
  • #20130

Powered by Codex Action

ahostbr · 3 months ago

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

zemeng5208 · 16 days ago

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

This is within the same local failure class as the confirmed helper-bin recovery reports in this issue family. The IAB tab bridge can read basic metadata, but deeper DOM/screenshot/CUA calls need the Node REPL/app-server path and fail with localized os error 3. The fact that a user-local Codex binary works while the packaged WindowsApps executable fails directly is exactly why the effective Desktop runtime path matters more than whether some codex command works in PowerShell.

WinBridge v3.1.1 resolves the current installed package/runtime, validates CODEX_CLI_PATH, Node REPL command/Node paths and user-side helper/bin state, and can reconstruct missing/stale user-owned runtime copies from the already installed official resources with staged SHA-256 verification and rollback data.

If those effective paths are current and valid and Browser DOM/screenshot calls still fail, that remaining Browser protocol/app-server integration is upstream. The tool does not patch WindowsApps or bypass Browser policy.