Browser Use and Chrome backend time out despite installed extension and valid native host

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

• #21908
• #21941
• #20678
• #21912
• #20846

Powered by Codex Action

Adding another macOS repro with a post-workaround check.

Environment:

• Codex Desktop: 26.506.31421 (build 2620)
• macOS: 15.7.7 (24G720), arm64
• Browser plugin: openai-bundled/browser-use 0.1.0-alpha2
• Chrome plugin: openai-bundled/chrome 0.1.7
• Google Chrome: 148.0.7778.98
• Codex Chrome Extension: 1.1.4_0

Observed:

• Browser plugin / in-app browser timed out while trying to open https://www.baidu.com. First attempt timed out after 30s and reset the JS kernel; retry timed out after 120s.
• Generic Playwright could open Baidu successfully, so the target site itself was reachable.
• Chrome plugin also timed out while trying to initialize/open an authenticated page.
• Diagnostics passed: Chrome running, extension installed/registered/enabled, and native messaging host manifest correct.

Tried the workaround from #21672:

• /tmp/codex-browser-use initially had one socket owned by extension-host and two sockets owned by the Codex app process.
• Removed only the non-extension-host socket pathnames and left the extension-host socket.
• Retried the Chrome plugin path; it still timed out after 90s.

So this looks like the same shared Browser Use / Chrome bridge issue, and after the #21672 socket cleanup it behaves more like #21681: only the extension-host socket remains visible, but browser backend discovery/runtime initialization still hangs.

Adding one more datapoint because this issue mentions both IAB and Chrome timing out, which is what I saw before isolating sockets.

On macOS with Codex Desktop 26.506.31421 / build 2620, Browser Use/IAB and Chrome were sharing /tmp/codex-browser-use. Chrome install checks were healthy:

• Chrome running
• Codex Chrome Extension 1.1.4_0 installed / registered / enabled
• native host manifest correct
• extension-host process alive

But the directory also had multiple Codex-owned IAB/browser-use socket pathnames. @Chrome timed out during setup/tab listing while those were present.

Moving only the non-extension-host socket pathnames aside made the Chrome backend work immediately; browser.user.openTabs() returned tabs. That makes this look like shared Browser Use socket discovery getting wedged on unrelated candidates, not a Chrome Web Store / install / regional gating problem.

Related: #21672 and #21719.

cc @cd-oai @mzeng-openai — this seems worth routing to whoever owns Codex Desktop browser-use backend discovery.

Adding a Windows repro with pipe-level evidence. This looks very close to the same shared Browser Use / Chrome backend discovery issue, but with an extra datapoint: disabling the Browser plugin does not remove the IAB backend from the runtime metadata.

Environment:

• OS: Windows
• Codex Desktop: 26.506.3741.0
• Chrome plugin: openai-bundled/chrome 0.1.7
• Browser plugin: openai-bundled/browser-use 0.1.0-alpha2, explicitly disabled
• Codex Chrome Extension: 1.1.4_0
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg

Config after full Codex Desktop restart:

[plugins."chrome@openai-bundled"]
enabled = true

[plugins."browser-use@openai-bundled"]
enabled = false

Chrome-side checks pass:

• check-extension-installed.js --json: installed / registered / enabled, version 1.1.4_0
• check-native-host-manifest.js --json: manifest exists, registry path matches, host name matches, allowed origin matches chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/
• Chrome native messaging pipes and extension-host.exe start after launching Chrome

Observed after restart:

• setupAtlasRuntime({ globals: globalThis }) from chrome/0.1.7/scripts/browser-client.mjs still times out after 45s.
• Node REPL request metadata still advertises both browser backends even though browser-use is disabled:

"x-codex-browser-use-available-backends": ["chrome", "iab"]

Windows named pipes include one Chrome extension pipe plus multiple IAB pipes:

codex-browser-use\\248563ee-dd11-46f4-baed-095fcc4866cb
codex-browser-use-18d7543c-812d-4b22-8d63-d45437f3f543
codex-browser-use-c16d3f7b-c351-490e-ad35-37bdb89df0f4

Direct JSON-RPC probing of those pipes shows Chrome itself is reachable:

{"jsonrpc":"2.0","id":1,"result":{"name":"Chrome","version":"1.1.4","type":"extension","metadata":{"extensionId":"hehggadaopoacecdllhhajmbjkdcmajg","extensionInstanceId":"5b9e8306-f171-46a7-bb91-b1846bb18693"}}}

One IAB pipe belongs to the current session:

{"name":"Codex In-app Browser","version":"26.506.31421","type":"iab","metadata":{"codexSessionId":"019e2c0d-eb56-7c50-99a8-e22602d3401e","codexWindowId":"1"}}

Another IAB pipe returns:

{"jsonrpc":"2.0","id":1,"error":{"code":1,"message":"Browser session does not belong to this IAB pipe"}}

So the Chrome extension/native host chain appears healthy, and the Chrome pipe can answer getInfo directly. The timeout appears to happen in the shared browser-client discovery/setup path while unrelated IAB pipes are present. The surprising part on Windows is that the Codex runtime still exposes iab and creates IAB pipes even when browser-use@openai-bundled is disabled in config and Codex Desktop has been fully restarted.

Expected:

• Disabling browser-use@openai-bundled should prevent IAB backend/pipe interference, or
• setupAtlasRuntime() should ignore non-matching / wrong-session / stale IAB pipes and still initialize the Chrome extension backend.

Adding a current macOS reproduction after applying the stale-socket workaround.

Environment:

• Codex Desktop: 26.803.61601 (build 6396)
• macOS: 26.6.1 (25G76), Apple Silicon
• Bundled Browser and Chrome plugins: 26.803.61601, installed and enabled
• Bundled Computer Use: 1.0.1000633, installed and enabled
• No CODEX_CLI_PATH override

Observed behavior:

• Normal interactive browsing and direct network access work.
• In-app Browser can control a local HTTP page, including DOM snapshot, screenshot, and link navigation.
• Public-page navigation/control through the Codex browser route times out and can reset the JS execution environment.
• Chrome initially timed out during connection/discovery as well.

Socket finding and partial workaround:

• /tmp/codex-browser-use contained about 54 socket pathnames.
• lsof showed only 11 held by the Codex app and one held by the Chrome extension host; most pathnames were stale.
• I moved every socket except the active extension-host socket to a temporary backup directory.
• After isolation, Chrome backend selection and documentation returned in about 0.2 seconds, where the same setup had previously timed out.
• However, a complete minimal test (new Chrome tab, goto https://example.com/, read title/URL, DOM snapshot) still timed out after about 30 seconds and reset the JS environment.

This appears to reproduce both layers discussed here: stale/unrelated socket discovery interference similar to #21672, followed by the non-responsive deep-control path similar to #21681. Socket isolation repairs discovery on this machine but does not repair navigation/DOM control. Restarting Codex and restarting the extension host did not resolve the second layer.

No Chrome profile data, cookies, browsing history, account data, proxy settings, or website-specific content were inspected or changed during this diagnosis.