Chrome plugin discovery still times out after socket cleanup; extension-host socket does not respond to getInfo

What version of the Codex App are you using?

Codex desktop app 26.506.21252.

Bundled Chrome plugin observed locally:

• plugin path: /Users/julian/.codex/plugins/cache/openai-bundled/chrome/0.1.7
• Codex Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Codex Chrome Extension version: 1.1.4_0

What platform is your computer?

macOS on Apple Silicon.

Chrome:

• Google Chrome 147.0.7727.138
• profile: Default

What issue are you seeing?

The new bundled Chrome plugin cannot complete browser backend discovery. Calls such as setupAtlasRuntime({ globals }), agent.browsers.get("extension"), and browser.user.openTabs() time out even after:

• reinstalling/re-enabling the Chrome plugin / Codex Chrome Extension,
• restarting Codex,
• restarting Chrome,
• deleting unrelated /tmp/codex-browser-use/*.sock socket pathnames,
• cold-starting Chrome from a clean /tmp/codex-browser-use directory.

This appears related to #21672, but this report is for the next failure mode after applying that workaround: even when /tmp/codex-browser-use contains only the Chrome extension-host socket, discovery still times out.

Expected behavior

With Chrome running and the Codex Chrome Extension/native host checks passing, the Chrome plugin should discover the extension backend and browser.user.openTabs() should return the open Chrome tabs.

Actual behavior

setupAtlasRuntime({ globals }) / Chrome backend discovery does not return before the Node REPL tool timeout. The browser task never reaches any page navigation.

Example minimal call that times out:

const { setupAtlasRuntime } = await import("/Users/julian/.codex/plugins/cache/openai-bundled/chrome/0.1.7/scripts/browser-client.mjs");
await setupAtlasRuntime({ globals: globalThis });
globalThis.browser = await agent.browsers.get("extension");
await browser.nameSession("Chrome health check");
const tabs = await browser.user.openTabs();

Local checks that pass

check-extension-installed.js --json reports:

{
  "extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "profilePath": "/Users/julian/Library/Application Support/Google/Chrome/Default",
  "installed": true,
  "registered": true,
  "enabled": true,
  "disabled": false,
  "versions": ["1.1.4_0"],
  "exitCode": 0
}

check-native-host-manifest.js --json reports:

{
  "manifestPath": "/Users/julian/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json",
  "expectedHostName": "com.openai.codexextension",
  "actualHostName": "com.openai.codexextension",
  "expectedExtensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "allowedOrigins": ["chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/"],
  "exists": true,
  "nameMatches": true,
  "hasExpectedOrigin": true,
  "correct": true,
  "problem": null
}

chrome-is-running.js --json reports Chrome running.

Socket state after applying #21672 workaround

After deleting non-Chrome socket pathnames and then doing a full Chrome cold restart, /tmp/codex-browser-use contained only one socket:

/tmp/codex-browser-use/692dd4b5-ca63-45f1-9caa-27d757a02e71.sock

lsof showed it was held by the Chrome extension-host process:

COMMAND     PID   USER   FD   TYPE NAME
extension 65436 julian    3u  unix /tmp/codex-browser-use/692dd4b5-ca63-45f1-9caa-27d757a02e71.sock

Chrome and the host were both fresh processes:

Google Chrome PID 65402, started Fri May 8 14:51:22 2026
extension-host PID 65436, started Fri May 8 14:51:26 2026

The visible socket directory was clean:

total 0
drwxrwxrwt@ 3 julian wheel 96 May 8 14:51 .
srw-------@ 1 julian wheel 0 May 8 14:51 692dd4b5-ca63-45f1-9caa-27d757a02e71.sock

Even in this state, setupAtlasRuntime({ globals }) still timed out.

Additional observation

A direct local framed JSON-RPC probe to the only extension-host socket connected but did not receive a response to ping/getInfo within a short timeout. This was only used as a diagnostic to identify the failing layer; the normal Chrome plugin path also times out in the same state.

Why this seems distinct from #21672

#21672 describes backend discovery hanging when unrelated browser-use sockets exist. That did happen initially on this machine: /tmp/codex-browser-use contained around 20 socket pathnames, and only one was owned by extension-host.

However, after removing all non-extension-host sockets and then cold-starting Chrome so only the new extension-host socket existed, the Chrome plugin still timed out. So there may be a second issue where the Chrome extension-host process is created and owns a socket but does not respond to the browser backend getInfo discovery request.

Suggested fix direction

• Add bounded per-candidate timeouts around Cc.create(...) and getInfo() during browser backend discovery.
• Emit diagnostics that identify which socket path/backend type timed out.
• For the Chrome path, either filter to the extension backend before waiting on all candidates or make non-responsive extension-host discovery fail with a specific error instead of causing a generic setup timeout.