Browser Use setup hangs on Windows when Chrome and IAB pipes are both present

What issue are you seeing?

Codex Desktop Browser Use initialization hangs indefinitely on Windows. Both @chrome and the in-app @browser entrypoints time out during setupAtlasRuntime({ globals: globalThis }) from the Node REPL tool.

This happens even though the Chrome extension, native host manifest, and backend named pipes are healthy and respond to direct JSON-RPC probes.

Environment

OS: Windows 11 Professional 10.0.26100 x64
Codex Desktop: OpenAI.Codex_26.506.2212.0_x64__2p2nqsd0c76g0
Codex CLI: 0.98.0
Chrome plugin: openai-bundled/chrome/0.1.7
Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha2
Codex Chrome Extension: 1.1.4
Chrome: 147.0.7727.138
Default browser: Google Chrome / ChromeHTML

Reproduction

From mcp__node_repl__js:

const { setupAtlasRuntime } = await import(
  'file:///C:/Users/user433/.codex/plugins/cache/openai-bundled/chrome/0.1.7/scripts/browser-client.mjs'
);
await setupAtlasRuntime({ globals: globalThis });

Observed result: the tool call times out after 45s and the Node REPL kernel resets.

The same behavior occurs with the in-app browser client path:

const { setupAtlasRuntime } = await import(
  'file:///C:/Users/user433/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha2/scripts/browser-client.mjs'
);
await setupAtlasRuntime({ globals: globalThis });

What was verified

Chrome plugin health checks all pass:

chrome-is-running.js --json: running=true
installed-browsers.js --json: default http/https = ChromeHTML, Chrome 147.0.7727.138
check-extension-installed.js --json: installed=true, registered=true, enabled=true, version=1.1.4_0
check-native-host-manifest.js --json: correct=true

After a clean Windows reboot, named pipes include multiple Browser Use backends:

\\.\pipe\codex-browser-use-406bfa7d-8948-4e1b-b563-357ae65a0f98
\\.\pipe\codex-browser-use-ad0e5497-c64a-4697-bfb1-2558c8490faf
\\.\pipe\codex-browser-use\1f89dc38-fc19-43bf-b173-c8dade293ed8

Using the same 4-byte length-prefixed JSON-RPC protocol as browser-client.mjs, direct getInfo probes return quickly for all three pipes when passing the current session_id and turn_id:

codex-browser-use-406bfa7d-... -> error: Browser session does not belong to this IAB pipe
codex-browser-use-ad0e5497-... -> result: Codex In-app Browser, version 26.506.21252, type iab
codex-browser-use\1f89dc38-... -> result: Chrome, version 1.1.4, type extension

Direct RPC to the Chrome extension pipe also works:

method=getUserTabs -> result=[] in ~37ms

So the backends are reachable and responsive outside setupAtlasRuntime(), but the official browser client initialization still hangs.

Logs

C:\Users\user433\.codex\logs_2.sqlite shows repeated codex-browser-use app-server initialization and Windows platform info, but no explicit error before the timeout:

app_server.client_name="codex-browser-use" app_server.client_version="0.1.0"
windows::current_platform is called
Returning Info { os_type: Windows, version: Semantic(10, 0, 26100), edition: Some("Windows 11 Professional"), bitness: X64, architecture: Some("x86_64") }

After each timed-out setup call, a child process remains temporarily:

codex.exe app-server --listen stdio://

Expected behavior

setupAtlasRuntime() should complete and expose agent.browsers.list() / agent.browsers.get('extension') when Chrome and IAB backends respond to getInfo.

If one discovered pipe is stale or belongs to another browser session, initialization should skip it or time it out rather than blocking the whole browser client setup.

Notes

This looks related in shape to #20678, but this report is Windows-specific and includes Chrome extension + IAB named pipes. Direct JSON-RPC calls to the same pipes succeed; only the official Node REPL browser-client initialization hangs.