›_ Codex Issues
Codex Issues / #19298

Browser Use IAB backend can see selected tab but cannot control it on Windows

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

Summary

The Browser Use plugin's in-app browser backend can discover the selected IAB tab, but control operations fail on Windows with failed to start codex app-server: 系统找不到指定的路径。 (os error 3).

This blocks navigation and DOM inspection through Browser Use, even when the in-app browser is already open and loaded.

Environment

  • OS: Windows
  • Codex desktop app
  • Browser Use plugin: 0.1.0-alpha1
  • In-app browser tab tested with: https://www.baidu.com/

What works

Using Browser Use's Node runtime setup with backend: "iab" succeeds, and the selected tab is visible:

const { setupAtlasRuntime } = await import('.../browser-client.mjs');
await setupAtlasRuntime({ globals: globalThis, backend: 'iab' });
await agent.browser.tabs.selected();

Observed selected tab shape:

{
  "selected": true,
  "title": "百度一下，你就知道",
  "url": "https://www.baidu.com/"
}

What fails

These operations fail:

await agent.browser.tabs.new();
await tab.goto('https://www.baidu.com/');
await tab.playwright.domSnapshot();

Error:

failed to start codex app-server: 系统找不到指定的路径。 (os error 3)

The stack points into the generated Browser Use Node kernel around kernel.js:1675.

Additional observations

  • Named pipe check showed only a codex-browser-use\\<uuid> pipe.
  • No codex-browser-use-iab pipe was present.
  • Retrying after restarting Codex produced a new codex-browser-use\\<uuid> pipe but still no codex-browser-use-iab pipe.
  • backend: "chrome" separately failed with expected native-host connection error, so this report is specifically about the IAB backend/app-server path.
  • The Chrome DevTools MCP fallback worked against the same in-app browser/page, so the browser page itself was reachable by another tool.

Expected behavior

After setupAtlasRuntime({ backend: 'iab' }) succeeds and the selected IAB tab is visible, Browser Use should be able to navigate, inspect DOM snapshots, and control the tab.

Actual behavior

Read-only tab discovery works, but control operations fail while starting codex app-server due to a missing path on Windows.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19187

Powered by Codex Action

mfushun-cmyk · 4 months ago

Additional confirmation from the same machine after checking the likely duplicate/root-cause thread (#19187 / #19271).

I verified this is still reproducible on the current Windows app package:

  • Codex Windows app package: OpenAI.Codex_26.422.2437.0_x64__2p2nqsd0c76g0
  • Install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.422.2437.0_x64__2p2nqsd0c76g0
  • Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha1

The bundled runtime exists but cannot be executed:

$pkg = Get-AppxPackage OpenAI.Codex
$node = Join-Path $pkg.InstallLocation 'app\resources\node.exe'
Test-Path -LiteralPath $node
& $node --version

Result:

True
Program 'node.exe' failed to run ... 拒绝访问。 / Access is denied.

So this appears to be the same Windows/MSIX runtime-launch issue as #19187 / #19271. Browser Use can discover the selected IAB tab, but anything that needs the Node/app-server path (tab.goto, domSnapshot, screenshot/control, nodeRepl.fetch) fails.

This blocks Browser Use on Windows desktop completely for practical use. Please prioritize a fix or provide an official workaround, for example allowing the Windows app to use a user-installed Node runtime instead of the bundled WindowsApps node.exe.

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

The follow-up workaround in this thread is strong evidence for a local path/materialization variant of this failure: Browser can initialize and see the IAB tab, but operations that need the app-server fail with os error 3; on one affected machine the expected %LOCALAPPDATA%\OpenAI\Codex\bin path was missing even though the helper binaries existed under the packaged LocalCache path, and restoring that path made Browser control work again.

WinBridge v3.1.1 generalizes that check instead of relying on one hard-coded junction: it resolves the current installed package/runtime, validates user-side CLI/Node REPL/app-server paths and stale hash/version references, verifies the official resources, and can reconstruct inconsistent user-owned runtime paths from the current official installation with staged copies, SHA-256 checks and rollback data.

I would still separate this from a case where codex app-server is already healthy and only Browser protocol/authenticated-fetch operations fail. WinBridge can repair the missing/stale executable-path layer; it cannot fix an upstream Browser runtime/API failure once those local paths are valid.

It does not modify WindowsApps ownership/ACLs or bypass Browser policy.