browser-use in-app browser hangs during initialization: setupAtlasRuntime({ globals: globalThis }) consistently times out in node_repl

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

Version: 26.506.31421 (2620)

What subscription do you have?

Free

What platform is your computer?

MacOS Tahoe 26.2

What issue are you seeing?

When using the browser-use:browser skill in Codex Desktop, the in-app browser runtime fails to initialize.

Running:

const { setupAtlasRuntime } = await import("/Users/wwi/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha2/scripts/browser-client.mjs");
await setupAtlasRuntime({ globals: globalThis });
consistently hangs and then times out after about 120 seconds.

Because of that, the next step never becomes usable:

globalThis.browser = await agent.browsers.get("iab");

What steps can reproduce the bug?

Verified facts
The plugin file exists:
/Users/wwi/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha2/scripts/browser-client.mjs
Running the same module from a normal node process fails immediately with:
privileged native pipe bridge is not available; browser-client is not trusted
In node_repl, it does not fail immediately with that error. Instead, it hangs deeper in initialization.
Codex Desktop logs show that the Browser Use native pipe server is listening and that the current turn was captured by the IAB route.
Relevant logs
Log file:

/Users/wwi/Library/Logs/com.openai.codex/2026/05/09/codex-desktop-348722e6-4403-4e16-9085-b15afa588d5e-4140-t0-i1-143843-0.log
Relevant lines:

2026-05-09T14:38:47.343Z info [browser-use-native-pipe-peer-authorizer] browser-use native pipe peer authorization enabled mode=packaged
2026-05-09T14:38:47.345Z info [browser-use-native-pipe-server] browser-use native pipe listening pipePath=/tmp/codex-browser-use/70d7e305-a264-4893-aeb0-8120f6d632b4.sock
2026-05-09T14:39:02.459Z info [browser-use-native-pipe-server] browser-use native pipe listening pipePath=/tmp/codex-browser-use/0d61eef9-8f83-4757-ae73-7f7eec90b0f5.sock
2026-05-09T14:47:27.093Z info [browser-session-registry] IAB_LIFECYCLE captured turn route conversationId=019e0d06-21f8-7553-96ed-58064379a96e disposeAfterTurn=false ownerWebContentsId=1 turnId=019e0d35-246c-7701-aad9-d23a672864aa windowId=1
Troubleshooting already performed
Initially suspected a permissions issue accessing /private/tmp/codex-browser-use.
Confirmed that even with broader access, the timeout still happened.
Deleted /private/tmp/codex-browser-use/*.sock, fully quit Codex, restarted Codex, and retried.
After restart, only 2 fresh socket files existed, so stale socket accumulation no longer seemed to be the primary cause.
Direct socket probing from a normal shell showed:
EPERM inside the sandbox
mostly ECONNREFUSED for older sockets outside the sandbox
newly created sockets were present but did not lead to a successful usable handshake path
Based on source inspection and logs, this does not look like:
Browser Use backend not starting
missing turn metadata
stale socket files being the primary cause
Current hypothesis
This looks more like a failure in the bridge path:

node_repl -> trusted browser-client -> native pipe -> iab backend

Specifically, node_repl appears to be trusted enough to enter the Browser Use path, but something in the native pipe connection / backend discovery / handshake path does not return and does not fail fast, causing setupAtlasRuntime(...) to hang until timeout.

Why I think this is a bridge/handshake issue rather than missing injection
If the context were completely untrusted, I would expect the same immediate error seen in normal node:
privileged native pipe bridge is not available; browser-client is not trusted
Instead, in node_repl, the call hangs rather than failing immediately.
Desktop logs also show:
native pipe server listening
IAB turn route captured
That suggests the environment is partially wired correctly, but the downstream connection/handshake path is getting stuck.

What is the expected behavior?

setupAtlasRuntime({ globals: globalThis }) should resolve successfully, and agent.browsers.get("iab") should allow normal Browser Use access to the in-app browser.

Additional information

_No response_