Codex Desktop Chrome plugin native host connects to different socket than Codex browser-use pipe and times out

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

• #21705
• #21681
• #21672

Powered by Codex Action

Codex 26.506.21252 / chrome@openai-bundled 0.1.7 / Codex Chrome Extension 1.1.4_0，extension installed/enabled, native messaging manifest correct, extension-host launched, but setupAtlasRuntime times out before listing tabs.

I am seeing the same failure on macOS after reinstalling the Chrome plugin and restarting both Codex App and Chrome.

Feedback correlation ID:

50cbd8fe-78ea-4fb1-b6ae-e8804bf10792

Session ID:

019e085a-286e-7b00-a715-3a675b41471d

Observed:

• Codex Chrome Extension popup shows Connected.
• Extension version: 1.1.4.
• Chrome extension is installed and enabled.
• Native host manifest check passes.
• Chrome can be operated through desktop UI / Computer Use.
• @Chrome still times out before listing tabs. The failing path is browser.user.openTabs() / setupAtlasRuntime().

Local socket signal:

extension-host and Codex appear to hold different /tmp/codex-browser-use/*.sock paths, matching this issue's socket mismatch hypothesis.

Read-only diagnostic update for Codex Chrome Extension v1.1.4 timeout.

Primary issue:

• openai/codex#21719

Environment:

• macOS 26.3.1
• Chrome 148.0.7778.97
• Codex Desktop: 26.506.31421

(observed via app metadata; this is a different build than the original
#21719 report's 26.506.21252)

• Codex Chrome Extension: v1.1.4_0
• Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Native messaging manifest exists at the expected user-level Chrome path.
• extension-host / native host process is running.

Socket evidence (lsof -nP -U):

• Codex process holds these sockets under /tmp/codex-browser-use:
• 36180320-a538-40e9-90af-56f33fb7a19e.sock
• d118dde5-84d8-4ed3-8ad6-518734d6adf4.sock
• 741441ab-ca1a-4ea3-b0bd-0ce70d5237d1.sock

• extension-host holds a different socket:
• f48107dc-9e0a-4649-a2a3-058e5b547734.sock

The extension-host socket does not match any socket currently held by Codex,
which is consistent with the split-socket condition described in this issue.

Adjacent checks:

• #21402 / multi-user shared socket ownership: /tmp/codex-browser-use is

owned by the current macOS user; no cross-user directory ownership mismatch
was observed.

• Native host not started: extension-host / native host is running, so this is

not a native-host startup failure case.

• #21681 / cold-start with only extension-host socket: this is not a cleaned-up

state; multiple Codex sockets are currently present.

• Unrelated socket cleanup: no cleanup was performed, so this report preserves

the original observed socket state.

Safety / privacy:

• No local repair action was performed.
• No /tmp/codex-browser-use/*.sock files were deleted.
• No Codex, Chrome, extension-host, or native host processes were killed.
• No extension or plugin reinstall was performed.
• No Chrome profile, cookies, cache, history, bookmarks, Local State,

Login Data, Gmail local data, account data, or synced browser data
were read.

• No proxy, VPN, TUN, Clash/Mihomo, Chrome profile, or system configuration

was changed.

Read-only diagnostic update for Codex Chrome Extension v1.1.4 timeout. Primary issue: Codex Desktop Chrome plugin native host connects to different socket than Codex browser-use pipe and times out #21719 Environment: macOS 26.3.1 Chrome 148.0.7778.97 Codex Desktop: 26.506.31421 (observed via app metadata; this is a different build than the original Codex Desktop Chrome plugin native host connects to different socket than Codex browser-use pipe and times out #21719 report's 26.506.21252) Codex Chrome Extension: v1.1.4_0 Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg Native messaging manifest exists at the expected user-level Chrome path. extension-host / native host process is running. Socket evidence (lsof -nP -U): Codex process holds these sockets under /tmp/codex-browser-use: 36180320-a538-40e9-90af-56f33fb7a19e.sock d118dde5-84d8-4ed3-8ad6-518734d6adf4.sock 741441ab-ca1a-4ea3-b0bd-0ce70d5237d1.sock extension-host holds a different socket: f48107dc-9e0a-4649-a2a3-058e5b547734.sock The extension-host socket does not match any socket currently held by Codex, which is consistent with the split-socket condition described in this issue. Adjacent checks: Browser Use IAB backend fails on multi-user macOS when shared temp socket path is owned by another user #21402 / multi-user shared socket ownership: /tmp/codex-browser-use is owned by the current macOS user; no cross-user directory ownership mismatch was observed. Native host not started: extension-host / native host is running, so this is not a native-host startup failure case. Chrome plugin discovery still times out after socket cleanup; extension-host socket does not respond to getInfo #21681 / cold-start with only extension-host socket: this is not a cleaned-up state; multiple Codex sockets are currently present. Unrelated socket cleanup: no cleanup was performed, so this report preserves the original observed socket state. Safety / privacy: No local repair action was performed. No /tmp/codex-browser-use/.sock files were deleted. No Codex, Chrome, extension-host, or native host processes were killed. No extension or plugin reinstall was performed. No Chrome profile, cookies, cache, history, bookmarks, Local State, Login Data, Gmail local data, account data, or synced browser data were read. * No proxy, VPN, TUN, Clash/Mihomo, Chrome profile, or system configuration was changed.

Also submitted via Codex feedback. Feedback/session ID: 741424e0-f729-4063-822a-cd659e654707

Another affected environment here.

Environment:

• macOS / Apple Silicon
• Codex Desktop: 26.506.31421
• Bundled Chrome plugin: openai-bundled/chrome 0.1.7
• Google Chrome: 147.0.7727.138
• Codex Chrome Extension: 1.1.4_0
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome profile: Default

What I verified:

• chrome-is-running.js --check passes.
• check-extension-installed.js --json reports installed/registered/enabled.
• check-native-host-manifest.js --json reports the native host manifest is correct.
• extension-host starts and owns a socket under /tmp/codex-browser-use.

Failure:

• Minimal @Chrome setup still times out before tab listing.
• Failing path: setupAtlasRuntime({ globals: globalThis }) / browser.user.openTabs().
• Local socket state showed multiple Codex-held /tmp/codex-browser-use/*.sock entries and a separate extension-host socket. Killing the old extension-host allowed Chrome to launch a fresh one, but openTabs() still timed out.
• Tried the #21672 socket cleanup workaround; it did not fix this machine.

No webpage-specific data was involved; this reproduces before any page interaction.

Another affected environment with a slightly narrower repro after Chrome restart.

Environment:

• macOS
• Codex Desktop: 26.506.31421
• Bundled Chrome plugin: openai-bundled/chrome 0.1.7
• Google Chrome: 148.0.7778.97
• Codex Chrome Extension: 1.1.4_0
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome profile: Default

Checks that pass:

• chrome-is-running.js --check
• check-extension-installed.js --json reports installed/registered/enabled
• check-native-host-manifest.js --json reports the native host manifest is correct
• extension-host is launched by Chrome and owns a socket under /tmp/codex-browser-use

Observed failure:

• @Chrome / setupAtlasRuntime({ globals: globalThis }) times out before tab listing.
• browser.user.openTabs() never returns.
• Killing an old extension-host, cleaning stale /tmp/codex-browser-use/*.sock, and letting Chrome launch a fresh extension-host did not fix it.
• After a full Chrome restart, I cleaned stale sockets again so only the newly launched extension-host socket remained. A direct read-only JSON-RPC getInfo probe to that socket still timed out after 3 seconds.

So in this run, the failure is not only stale socket enumeration on the Codex side. Even the fresh post-Chrome-restart extension-host socket accepts a connection but does not answer getInfo, and setupAtlasRuntime() then times out.

No webpage-specific interaction was involved; this reproduces before touching Colab or any other tab content.

Another affected environment on macOS with a protocol-level observation that may pinpoint why extension-host sockets accept connections but never answer getInfo.

Environment

• Codex Desktop: 26.506.31421 (build 2620)
• macOS: Darwin 25.1.0 / Apple Silicon
• Google Chrome: 148.0.7778.97
• Bundled Chrome plugin: openai-bundled/chrome 0.1.7
• Codex Chrome Extension: 1.1.4_0 (id hehggadaopoacecdllhhajmbjkdcmajg)
• Codex session id: 1158f5af-2da8-4e53-bfb3-c0e61cb8804c

Confirmed existing signals

Same split-socket pattern as the original report and other comments:

• Codex main process holds multiple listening sockets under /tmp/codex-browser-use/, mode 0755
• extension-host holds its own listening socket, mode 0600
• No peer connection exists in either direction — both sides are stuck in listen()
• The two different permission modes suggest two independent code paths minting sockets without a shared registry

Clean-start reproduction also matched #21681: after fully quitting Codex + Chrome, killing orphan extension-host, clearing /tmp/codex-browser-use/*.sock, and relaunching, @chrome still times out on the first try.

New signal: extension-host never opens stdin/stdout

This is the detail I don't see in the existing comments. lsof -p <extension-host-pid> on the process Chrome forks through native messaging shows:

extension-host  PID  fd  2u  CHR   /dev/null
extension-host  PID  fd  3u  unix  /tmp/codex-browser-use/<uuid>.sock

fd 0 (stdin) and fd 1 (stdout) are not present.

Chrome Native Messaging requires the host process to use stdin/stdout as the bidirectional message pipe with the extension service worker. With those descriptors absent:

• The service worker cannot receive the extension-host's socket path
• The service worker cannot deliver Codex's socket path to extension-host
• Neither side can discover the other, so both end up listening on sockets nothing ever connects to

This is consistent with #21681's observation that even a fresh post-Chrome-restart extension-host socket accepts a connection but hangs on getInfo — the process simply has no channel to learn which peer it should be serving.

Related secondary symptoms

1. Orphan processes survive Chrome restart. After quitting Chrome, the old extension-host gets reparented to pid 1 (launchd) and keeps running, because with no stdin it never sees EOF. Relaunching Chrome spawns a fresh extension-host alongside the orphan; both listen on different sockets.

1. Socket leak on every @chrome invocation. Codex creates a new 0755 socket each time @chrome is invoked, and none are unlinked across retries or across Codex app restarts (stale 0600 sockets from prior sessions persist too).

1. Version skew suspicion. Bundle ships extension-host 0.1.7 while the Web Store extension is 1.1.4. The major version gap, combined with the missing stdio handshake, is consistent with a protocol-version mismatch between the two components.

Workarounds tried, none worked

• Reinstalling the Codex Chrome Extension (uninstall from chrome://extensions then reinstall via Codex flow)
• Clearing /tmp/codex-browser-use/*.sock with Codex fully quit
• Killing all stale extension-host and SkyComputerUseClient mcp orphans
• Fully quitting and relaunching Chrome (the --restart --restart state appears even after clean quit)
• Fully quitting and relaunching Codex Desktop
• Combining all of the above in a single sequence

Suggested fix direction (extends #21681's suggestions)

• Verify the bundled extension-host binary actually reads/writes Chrome Native Messaging framed messages on stdin/stdout before starting any socket dance — if the protocol is intentionally different, surface a specific error identifying that the host isn't speaking native-messaging.
• Ship an extension-host version matched to the current Web Store extension (or pin the extension to a compatible version).
• Single source of truth for the socket path: pick one code path (Node-side or native), write the path into a known location (e.g. ~/.codex/browser-use-registry.json) with a file lock, and have the other side read from it instead of both minting UUID paths.
• Have extension-host exit on EOF on stdin so orphans don't survive Chrome lifecycle events.

Codex Chrome plugin hangs at setupAtlasRuntime after reinstall/restart

Issue

Codex Chrome Extension API cannot initialize. setupAtlasRuntime({ globals: globalThis }) hangs until timeout, even after reinstalling the Chrome plugin, restarting Codex, and restarting Chrome.

Observed

• Chrome is running.
• Codex Chrome Extension is installed and enabled.
• Extension version: 1.1.4.
• Native Messaging Host manifest check passes.
• Chrome profile is Default.
• extension-host process exists.
• /tmp/codex-browser-use/*.sock exists and is held by extension-host.
• Old/stale sockets were removed and extension was toggled off/on.
• setupAtlasRuntime still hangs.
• browser.user.openTabs() is never reached because initialization does not complete.

Key Symptom

setupAtlasRuntime hangs even after reinstall/restart; extension-host socket exists but does not respond.

Expected

setupAtlasRuntime should complete, then agent.browsers.get("extension") and browser.user.openTabs() should return Chrome tabs.

Environment

• macOS
• Google Chrome 147.0.7727.139
• Codex Chrome Extension 1.1.4
• Chrome profile: Default

Troubleshooting Already Tried

• Restarted Chrome.
• Restarted Codex.
• Reinstalled Codex Chrome plugin from Codex plugin UI.
• Verified extension installed/enabled.
• Verified native host manifest.
• Opened a fresh Chrome window.
• Toggled extension off/on.
• Removed stale /tmp/codex-browser-use/*.sock.
• Confirmed extension-host process and socket exist.

Impact

Chrome Extension API is unusable; authenticated browser automation has to fall back to Computer Use screenshots.

Adding a fresh repro from another macOS/Apple Silicon machine, because this still reproduces on the current desktop build and the workaround result is useful.

Environment:

• Codex Desktop: 26.506.31421 / build 2620
• Chrome plugin: openai-bundled/chrome 0.1.7
• Browser plugin: openai-bundled/browser-use 0.1.0-alpha2
• Google Chrome: 148.0.7778.168
• Codex Chrome Extension: 1.1.4_0
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome profile: Default

Checks that passed:

• Chrome running
• Extension installed / registered / enabled
• Native host manifest correct for com.openai.codexextension
• extension-host running and owning a socket under /tmp/codex-browser-use

Failure before workaround:

• @Chrome timed out at setup / tab listing.
• /tmp/codex-browser-use contained one extension-host socket plus several Codex-owned in-app/browser-use sockets.

Workaround result:

• Moved only the non-extension-host socket pathnames out of /tmp/codex-browser-use.
• Left the Chrome extension-host socket in place.
• Retried the same Chrome backend call.
• browser.user.openTabs() immediately succeeded and returned the open Chrome tabs.

So this machine matches the split/shared-socket discovery issue rather than a broken Chrome install or region/gating issue. The Chrome extension/native host were healthy; the failure was browser backend discovery hanging on unrelated Codex/IAB sockets.

Suggested product fix still seems to be: filter by requested backend before waiting on every socket, add short per-candidate getInfo timeouts, ignore wrong-session/stale sockets, and surface the specific socket/backend that timed out instead of resetting the JS kernel.

cc @khoi-oai @charley-openai — this issue now has several independent macOS repros with passing install checks and socket-level evidence. Could someone from the Codex app/browser-use side take a look or route it to the right owner?

I’m seeing a closely related macOS failure on current Codex Desktop/Chrome plugin after reinstall and reboot.

Environment:

• macOS, Apple Silicon
• Codex Desktop release shown in logs: 26.527.31326
• Google Chrome: 148.0.7778.179
• Codex Chrome Extension: 1.1.5_0
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome plugin cache: openai-bundled/chrome/26.527.31326

Checks that pass:

• Chrome is installed and running.
• The Codex Chrome Extension is installed and enabled in the selected Default profile.
• Native messaging host manifest exists and is correct:
• host: com.openai.codexextension
• allowed origin: chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/
• path points to .../.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/macos/arm64/extension-host
• browser-client.mjs SHA256 matches NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S.
• codesign --verify --strict passes for Codex.app, bundled node, node_repl, and extension-host.

Actual behavior:

• agent.browsers.get('extension') fails with Browser is not available: extension.
• agent.browsers.list() returns [].
• Codex desktop log reports:

``text
browser-use native pipe rejected socket peer reason=missing-code-signing-identity
``

• Socket evidence after restart shows Codex and extension-host are on different browser-use sockets:

``text
Codex ... /tmp/codex-browser-use/fb9f67d7-c378-48b5-abce-bc6b5c13da27.sock
extension ... /tmp/codex-browser-use/4b95b413-d9e7-4c4d-acdb-9911772e8742.sock
``

Local recovery attempts that did not fix it:

• Reinstalled Chrome plugin / extension and rebooted.
• Killed extension-host and let Chrome relaunch it.
• Removed stale browser-use socket files not held by a live process.
• Retried lightweight agent.browsers.list() / agent.browsers.get('extension') checks.

This still looks like a Codex Desktop browser-use native pipe / peer authorization / socket wiring issue rather than a Chrome extension installation problem.

Confirming this is still present on a much newer build, and capturing the "native host attached to the wrong/stale socket" evidence requested in the original report. To the model it surfaces as privileged native pipe bridge is not available; browser-client is not trusted — I believe this is the same root cause as #25247.

Environment

• Codex desktop app build 26.611.62324 (engine codex-cli 0.140.0-alpha.19)
• Codex Chrome extension 1.1.5 (hehggadaopoacecdllhhajmbjkdcmajg)
• Google Chrome 149.0.7827.115
• macOS 26.3.1, Apple Silicon (arm64)
• Native-messaging host com.openai.codexextension: manifest valid, allowed_origins correct, host binary present (mode 755)

The trust check is not the failure — there is simply no pipe. …/chrome/26.611.62324/scripts/browser-client.mjs hashes to exactly the NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S configured for node_repl (eb55d24cf065cd5311af6f99b16bade2b7a670790ff2db9accf60d012dd55dd1), and it lives under NODE_REPL_TRUSTED_CODE_PATHS (~/.codex). Both trust gates pass. A REPL probe shows the runtime never receives the pipe at all:

{ hasNativePipe: false, nativePipeKeys: null }

So "not trusted" is downstream of the missing pipe (cf. #25247: nodeRepl.nativePipe false).

The socket mismatch, pinned to pids. With Chrome + Codex both up and a thread issuing a browser action, the desktop app and the extension-host each stand up their own /tmp/codex-browser-use/<uuid>.sock listener and never connect to each other:

# desktop (Codex.app main process)
Codex      <pid_a>  …  129u  unix  …/codex-browser-use/287a439b-….sock   (listener)
# native-messaging host launched by Chrome
extension  <pid_b>  …    3u  unix  …/codex-browser-use/310858f6-….sock   (listener)

Neither fd shows a peer (->) to the other's socket. The extension-host waits on one socket while the app-server waits on a different one — exactly "connects to a different socket than the browser-use pipe," here pinned to concrete pids/inodes.

A second, compounding bug: stale registry presence. ~/.codex/chrome-native-hosts-v2.json entries[0].presence.pid pointed at a process that had already quit (from a prior day), with proxyPort: 0. There were also 13 orphaned /tmp/codex-browser-use/*.sock accumulated over several days — the bridge appears to create a fresh socket per attempt and never reaps them, and presence is not refreshed to a live pid on plain app launch (only on the first browser action).

What does NOT fix it (matches the original report, plus more):

• Full Chrome quit/relaunch
• Full Codex quit/relaunch
• Killing extension-host and letting Chrome respawn it
• Deleting both chrome-native-hosts*.json and all /tmp/codex-browser-use/*.sock, then relaunching from a clean slate

After the clean slate the registry is rewritten with a live pid (so the stale-presence bug is resolved) — but the two-socket mismatch reproduces immediately and the model still gets …browser-client is not trusted. The stale presence is a real but separate bug; the core defect is that the two halves never rendezvous on a shared socket even when freshly initialized.

Possible contributing factor. This host runs multiple Codex installs against one CODEX_HOME (~/.codex): the desktop app, a global npm @openai/codex CLI (also used as a --listen/proxy SSH bridge), and editor-embedded copies. They share one native-messaging host name and one chrome-native-hosts*.json, so the broker "presence" gets overwritten/churned — at one point a plain codex app-server from the npm install had claimed the broker slot with a pid that later died. The socket mismatch still reproduces with the desktop app as the sole broker, so multi-install churn aggravates but is not the root cause.

Questions / asks

1. How are extension-host and the desktop app-server supposed to agree on the /tmp/codex-browser-use/<uuid>.sock path? Empirically each creates its own listener — what's the intended rendezvous (a registry field, a native-messaging handshake message, an env var)? That handoff looks like where it breaks.
2. Refresh chrome-native-hosts-v2.json presence to the live pid on launch, and reap stale /tmp/codex-browser-use/*.sock.
3. Surface an explicit error when nodeRepl.nativePipe is absent (the earlier request in this thread) instead of the generic "not trusted."
4. Guard/namespace per-install when multiple Codex builds share one CODEX_HOME.

Diagnostic recipe for others hitting this (run while Chrome + Codex are up and a browser action has been attempted):

for s in /tmp/codex-browser-use/*.sock; do
  echo "$s <- $(lsof "$s" 2>/dev/null | awk 'NR>1{print $1" pid="$2; exit}')"
done
# If the Codex desktop pid and the extension-host pid hold DIFFERENT .sock files
# (and neither shows a peer), you're hitting this.

python3 -c 'import json,os;e=json.load(open(os.path.expanduser("~/.codex/chrome-native-hosts-v2.json")))["entries"][0];print("presence.pid",e["presence"]["pid"],"proxyPort",e.get("proxyPort"))'
ps -p <that pid>   # often already dead

Additional reproduction from macOS where the backend is initially discovered and correctly bound, but the next Chrome operation never returns.

Environment

• macOS 15.7.7 (arm64)
• ChatGPT/Codex Desktop: 26.707.72221
• Codex CLI: 0.144.4
• Thread ID: 019f6144-c63f-7252-8e74-edab813d4a10
• Bundled Chrome runtime path includes: chrome/26.707.72221

Observed sequence

1. In the same local Desktop thread, setupBrowserRuntime({ globals: globalThis }) completed.
2. agent.browsers.list() returned both:

• Chrome with type: "extension"
• Codex In-app Browser with type: "iab"

1. The IAB metadata contained the exact current codexSessionId: 019f6144-c63f-7252-8e74-edab813d4a10. This rules out the backend being attached only to another thread at that point.
2. agent.browsers.get("extension") succeeded and returned the Chrome control documentation.
3. The next browser call ran nameSession(), user.openTabs(), then intended to claim/create a tab and navigate.
4. The rollout JSONL contains the browser function call at 2026-07-15T09:49:10.968Z, but no corresponding function_call_output. The rollout file ends at that call. There is no timeout result or actionable error.

Earlier in the same thread, agent.browsers.list() had intermittently returned [], then became populated after the thread was re-opened through the Desktop deep link and the browser runtime was initialized again.

Expected

Once the Chrome backend is discovered and bound to the current thread, user.openTabs() and subsequent browser calls should either complete or fail with a diagnostic error. A new turn or routine browser operation should not silently invalidate the binding or terminate the execution chain.

Actual

The backend can be present and correctly associated with the current session, yet a subsequent browser call can hang or terminate the execution chain without a tool result.

This appears related to the socket/session lifecycle described here, but adds a distinct failure mode: successful backend discovery and correct session metadata do not guarantee that the next Chrome operation will return.