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

[Timmycosmos]

Summary

Codex Desktop Browser Use appears unable to connect to either the in-app browser (iab) or the Chrome extension backend. Both paths time out at the browser-client connection/listing stage.

This looks like a Browser Use/native pipe runtime issue rather than a Chrome extension installation issue.

Environment

• OS: macOS
• Chrome: 147.0.7727.139
• Codex Chrome Extension: 1.1.4
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Codex Desktop app: 26.506.31421

What I checked

Chrome side appears healthy:

• Google Chrome is installed and running.
• Codex Chrome Extension is installed and enabled in the Default profile.
• Native Messaging Host manifest exists and points to:
  /Users/timmy/.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/macos/arm64/extension-host
• Manifest allowed_origins matches:
  chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/
• The native extension-host process starts and opens a socket under:
  /tmp/codex-browser-use/*.sock

Browser plugin side was also restored/verified:

• [plugins."browser-use@openai-bundled"] enabled = true
• Browser plugin cache exists at:
  /Users/timmy/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha2

Actual behavior

Both browser backends fail:

• agent.browsers.list() times out.
• In-app browser (iab) does not become usable.
• Chrome backend also times out and cannot list tabs.

In Node REPL, import.meta.__codexNativePipe is undefined, even though request metadata advertises available browser backends:

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

Expected behavior

Codex should be able to initialize Browser Use and return available browser backends via browsers.list(), then connect to either the in-app browser or Chrome extension backend.

Notes

This may be related to the Browser Use / Chrome extension feature being new. The symptoms suggest the extension and native host are installed correctly, but the Codex Desktop runtime is not injecting or wiring the native pipe needed by browser-client.

[github-actions]

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

• Chrome plugin backend times out even though extension native host reports connected #21908
• browser-use in-app browser hangs during initialization: setupAtlasRuntime({ globals: globalThis }) consistently times out in node_repl #21941
• fix(browser): Browser Use cannot connect to IAB from Node REPL on macOS #20678
• Windows: browser-use@openai-bundled times out and never starts the in-app browser (iab), while @chrome can connect #21912
• Browser Use IAB backend fails to connect on Windows #20846

Powered by Codex Action

[liuyt-atom]

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.

[Ahmet-Dedeler]

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.

[fengqin616]

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.