Repository navigation
Codex Desktop Chrome plugin native host connects to different socket than Codex browser-use pipe and times out #21719
Description
What version of the Codex App are you using?
Codex Desktop 26.506.21252
What platform is your computer?
macOS, Apple Silicon
What issue are you seeing?
The bundled Chrome plugin cannot connect to Chrome through the Codex Chrome Extension. Any @chrome task that tries to read tabs, for example browser.user.openTabs(), hangs until the tool call times out after 60 seconds.
This is not a webpage-specific failure. It reproduces before navigation, with a minimal open-tabs check.
Environment / versions
- Codex Desktop:
26.506.21252 - Chrome plugin:
chrome@openai-bundled/ plugin files underchrome/0.1.7 - Codex Chrome Extension ID:
hehggadaopoacecdllhhajmbjkdcmajg - Chrome Extension version:
1.1.4_0 - Google Chrome:
148.0.7778.96 - Chrome profile checked by plugin scripts:
Profile 1
What I verified
The plugin's own checks pass:
- Chrome is installed and running.
- Codex Chrome Extension is installed, registered, and enabled in
Profile 1. - Native messaging host manifest exists and is correct.
- Manifest host name is
com.openai.codexextension. - Manifest
allowed_originsincludeschrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/. - Native host process starts successfully when Chrome runs.
The issue persists after:
- Fully quitting and restarting Chrome.
- Fully quitting and restarting Codex Desktop.
- Disabling and re-enabling the Codex Chrome Extension.
- Killing the
extension-hostprocess and letting Chrome relaunch it. - Reinstalling the Chrome plugin.
Diagnostic signal
After a full restart, Codex and Chrome are both new processes and the extension native host starts, but the sockets do not line up.
Example after full restart:
Codex process holds:
/tmp/codex-browser-use/f766e672-6e34-480f-9b54-517996008edd.sock
/tmp/codex-browser-use/8119b1af-d72f-49e9-a994-cc24ce76ce63.sock
Chrome extension-host process holds:
/tmp/codex-browser-use/29c615a1-11e1-46af-8278-6d00d36366a9.sock
Earlier retries showed the same pattern with different UUIDs: Codex listens on two browser-use sockets, while extension-host connects to a separate socket. The native host process is alive, but it never appears to connect to the active Codex browser-use pipe, and the model-side browser client waits until timeout.
Steps to reproduce
- Install/enable the bundled Chrome plugin in Codex Desktop.
- Ensure the Codex Chrome Extension is installed and enabled in Chrome
Profile 1. - Start Codex Desktop and Chrome.
- Ask Codex to use
@chrome, or run a minimal connection check that callsbrowser.user.openTabs(). - Observe the call hangs for 60 seconds and times out.
- Inspect local Unix sockets with
lsof -U | rg 'codex-browser-use|extension-host|codexextension'. - Observe that the Codex process and Chrome
extension-hostprocess are attached to different/tmp/codex-browser-use/*.sockpaths.
Expected behavior
The Chrome extension native host should connect to the active Codex browser-use/native pipe, and browser.user.openTabs() should return the open Chrome tabs quickly.
Actual behavior
The native host starts, but attaches to a different socket from the Codex browser-use sockets. browser.user.openTabs() never returns and the Node REPL/browser-client tool call times out after 60 seconds.
Additional notes
Running the browser client outside the trusted Codex runtime fails immediately with:
privileged native pipe bridge is not available; browser-client is not trusted
Inside the trusted Codex runtime, the same setup path hangs rather than returning a diagnostic error. A clearer error when the native host is attached to the wrong/stale socket would make this much easier to diagnose.
Activity
github-actions commentedon May 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
caaaptaintop commentedon May 8, 2026
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.
Astro-Han commentedon May 8, 2026
I am seeing the same failure on macOS after reinstalling the Chrome plugin and restarting both Codex App and Chrome.
Feedback correlation ID:
Session ID:
Observed:
Connected.1.1.4.@Chromestill times out before listing tabs. The failing path isbrowser.user.openTabs()/setupAtlasRuntime().Local socket signal:
extension-hostandCodexappear to hold different/tmp/codex-browser-use/*.sockpaths, matching this issue's socket mismatch hypothesis.KitschLam commentedon May 9, 2026
Read-only diagnostic update for Codex Chrome Extension v1.1.4 timeout.
Primary issue:
Environment:
(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)
Socket evidence (lsof -nP -U):
Codex process holds these sockets under /tmp/codex-browser-use:
extension-host holds a different socket:
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:
owned by the current macOS user; no cross-user directory ownership mismatch
was observed.
not a native-host startup failure case.
state; multiple Codex sockets are currently present.
the original observed socket state.
Safety / privacy:
Login Data, Gmail local data, account data, or synced browser data
were read.
was changed.
KitschLam commentedon May 9, 2026
Also submitted via Codex feedback. Feedback/session ID: 741424e0-f729-4063-822a-cd659e654707
heartInsert commentedon May 9, 2026
Another affected environment here.
Environment:
26.506.31421openai-bundled/chrome 0.1.7147.0.7727.1381.1.4_0hehggadaopoacecdllhhajmbjkdcmajgDefaultWhat I verified:
chrome-is-running.js --checkpasses.check-extension-installed.js --jsonreports installed/registered/enabled.check-native-host-manifest.js --jsonreports the native host manifest is correct.extension-hoststarts and owns a socket under/tmp/codex-browser-use.Failure:
@Chromesetup still times out before tab listing.setupAtlasRuntime({ globals: globalThis })/browser.user.openTabs()./tmp/codex-browser-use/*.sockentries and a separateextension-hostsocket. Killing the oldextension-hostallowed Chrome to launch a fresh one, butopenTabs()still timed out.No webpage-specific data was involved; this reproduces before any page interaction.
caidwang commentedon May 10, 2026
Another affected environment with a slightly narrower repro after Chrome restart.
Environment:
26.506.31421openai-bundled/chrome 0.1.7148.0.7778.971.1.4_0hehggadaopoacecdllhhajmbjkdcmajgDefaultChecks that pass:
chrome-is-running.js --checkcheck-extension-installed.js --jsonreports installed/registered/enabledcheck-native-host-manifest.js --jsonreports the native host manifest is correctextension-hostis launched by Chrome and owns a socket under/tmp/codex-browser-useObserved failure:
@Chrome/setupAtlasRuntime({ globals: globalThis })times out before tab listing.browser.user.openTabs()never returns.extension-host, cleaning stale/tmp/codex-browser-use/*.sock, and letting Chrome launch a freshextension-hostdid not fix it.extension-hostsocket remained. A direct read-only JSON-RPCgetInfoprobe 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-hostsocket accepts a connection but does not answergetInfo, andsetupAtlasRuntime()then times out.No webpage-specific interaction was involved; this reproduces before touching Colab or any other tab content.
Yukioa2z commentedon May 11, 2026
Another affected environment on macOS with a protocol-level observation that may pinpoint why
extension-hostsockets accept connections but never answergetInfo.Environment
26.506.31421(build 2620)148.0.7778.97openai-bundled/chrome 0.1.71.1.4_0(idhehggadaopoacecdllhhajmbjkdcmajg)1158f5af-2da8-4e53-bfb3-c0e61cb8804cConfirmed existing signals
Same split-socket pattern as the original report and other comments:
/tmp/codex-browser-use/, mode 0755extension-hostholds its own listening socket, mode 0600listen()Clean-start reproduction also matched #21681: after fully quitting Codex + Chrome, killing orphan
extension-host, clearing/tmp/codex-browser-use/*.sock, and relaunching,@chromestill 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: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:
This is consistent with #21681's observation that even a fresh post-Chrome-restart
extension-hostsocket accepts a connection but hangs ongetInfo— the process simply has no channel to learn which peer it should be serving.Related secondary symptoms
Orphan processes survive Chrome restart. After quitting Chrome, the old
extension-hostgets reparented to pid 1 (launchd) and keeps running, because with no stdin it never sees EOF. Relaunching Chrome spawns a freshextension-hostalongside the orphan; both listen on different sockets.Socket leak on every
@chromeinvocation. Codex creates a new 0755 socket each time@chromeis invoked, and none are unlinked across retries or across Codex app restarts (stale 0600 sockets from prior sessions persist too).Version skew suspicion. Bundle ships
extension-host0.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
chrome://extensionsthen reinstall via Codex flow)/tmp/codex-browser-use/*.sockwith Codex fully quitextension-hostandSkyComputerUseClient mcporphans--restart --restartstate appears even after clean quit)Suggested fix direction (extends #21681's suggestions)
extension-hostbinary 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.extension-hostversion matched to the current Web Store extension (or pin the extension to a compatible version).~/.codex/browser-use-registry.json) with a file lock, and have the other side read from it instead of both minting UUID paths.extension-hostexit on EOF on stdin so orphans don't survive Chrome lifecycle events.Nielsony commentedon May 12, 2026
Codex Chrome plugin hangs at
setupAtlasRuntimeafter reinstall/restartIssue
Codex Chrome Extension API cannot initialize.
setupAtlasRuntime({ globals: globalThis })hangs until timeout, even after reinstalling the Chrome plugin, restarting Codex, and restarting Chrome.Observed
1.1.4.Default.extension-hostprocess exists./tmp/codex-browser-use/*.sockexists and is held byextension-host.setupAtlasRuntimestill 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
setupAtlasRuntimeshould complete, thenagent.browsers.get("extension")andbrowser.user.openTabs()should return Chrome tabs.Environment
147.0.7727.1391.1.4DefaultTroubleshooting Already Tried
/tmp/codex-browser-use/*.sock.extension-hostprocess and socket exist.Impact
Chrome Extension API is unusable; authenticated browser automation has to fall back to Computer Use screenshots.
Ahmet-Dedeler commentedon May 14, 2026
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:
26.506.31421/ build2620openai-bundled/chrome 0.1.7openai-bundled/browser-use 0.1.0-alpha2148.0.7778.1681.1.4_0hehggadaopoacecdllhhajmbjkdcmajgDefaultChecks that passed:
com.openai.codexextensionextension-hostrunning and owning a socket under/tmp/codex-browser-useFailure before workaround:
@Chrometimed out at setup / tab listing./tmp/codex-browser-usecontained oneextension-hostsocket plus several Codex-owned in-app/browser-use sockets.Workaround result:
extension-hostsocket pathnames out of/tmp/codex-browser-use.extension-hostsocket in place.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
getInfotimeouts, 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?
doctor-clawler commentedon May 31, 2026
I’m seeing a closely related macOS failure on current Codex Desktop/Chrome plugin after reinstall and reboot.
Environment:
26.527.31326148.0.7778.1791.1.5_0hehggadaopoacecdllhhajmbjkdcmajgopenai-bundled/chrome/26.527.31326Checks that pass:
Defaultprofile.com.openai.codexextensionchrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/.../.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/macos/arm64/extension-hostbrowser-client.mjsSHA256 matchesNODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S.codesign --verify --strictpasses for Codex.app, bundlednode,node_repl, andextension-host.Actual behavior:
agent.browsers.get('extension')fails withBrowser is not available: extension.agent.browsers.list()returns[].Local recovery attempts that did not fix it:
extension-hostand let Chrome relaunch it.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.
cypres0099 commentedon Jun 18, 2026
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
26.611.62324(enginecodex-cli 0.140.0-alpha.19)1.1.5(hehggadaopoacecdllhhajmbjkdcmajg)149.0.7827.11526.3.1, Apple Silicon (arm64)com.openai.codexextension: manifest valid,allowed_originscorrect, host binary present (mode 755)The trust check is not the failure — there is simply no pipe.
…/chrome/26.611.62324/scripts/browser-client.mjshashes to exactly theNODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256Sconfigured fornode_repl(eb55d24cf065cd5311af6f99b16bade2b7a670790ff2db9accf60d012dd55dd1), and it lives underNODE_REPL_TRUSTED_CODE_PATHS(~/.codex). Both trust gates pass. A REPL probe shows the runtime never receives the pipe at all:So "not trusted" is downstream of the missing pipe (cf. #25247:
nodeRepl.nativePipefalse).The socket mismatch, pinned to pids. With Chrome + Codex both up and a thread issuing a browser action, the desktop app and the
extension-hosteach stand up their own/tmp/codex-browser-use/<uuid>.socklistener and never connect to each other: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.jsonentries[0].presence.pidpointed at a process that had already quit (from a prior day), withproxyPort: 0. There were also 13 orphaned/tmp/codex-browser-use/*.sockaccumulated over several days — the bridge appears to create a fresh socket per attempt and never reaps them, andpresenceis 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):
extension-hostand letting Chrome respawn itchrome-native-hosts*.jsonand all/tmp/codex-browser-use/*.sock, then relaunching from a clean slateAfter 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/codexCLI (also used as a--listen/proxySSH bridge), and editor-embedded copies. They share one native-messaging host name and onechrome-native-hosts*.json, so the broker "presence" gets overwritten/churned — at one point a plaincodex app-serverfrom 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
extension-hostand the desktop app-server supposed to agree on the/tmp/codex-browser-use/<uuid>.sockpath? 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.chrome-native-hosts-v2.jsonpresenceto the live pid on launch, and reap stale/tmp/codex-browser-use/*.sock.nodeRepl.nativePipeis absent (the earlier request in this thread) instead of the generic "not trusted."CODEX_HOME.Diagnostic recipe for others hitting this (run while Chrome + Codex are up and a browser action has been attempted):
yunfei-DONNli commentedon Jul 15, 2026
Additional reproduction from macOS where the backend is initially discovered and correctly bound, but the next Chrome operation never returns.
Environment
019f6144-c63f-7252-8e74-edab813d4a10chrome/26.707.72221Observed sequence
setupBrowserRuntime({ globals: globalThis })completed.agent.browsers.list()returned both:Chromewithtype: "extension"Codex In-app Browserwithtype: "iab"codexSessionId:019f6144-c63f-7252-8e74-edab813d4a10. This rules out the backend being attached only to another thread at that point.agent.browsers.get("extension")succeeded and returned the Chrome control documentation.nameSession(),user.openTabs(), then intended to claim/create a tab and navigate.2026-07-15T09:49:10.968Z, but no correspondingfunction_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.