Codex Desktop Chrome plugin times out during extension handshake despite extension and native host checks passing

[ZengEric]

Summary

The Codex Desktop bundled Chrome plugin cannot communicate with the Codex Chrome Extension. The local diagnostics all pass, but the first lightweight extension-backed call times out repeatedly.

Environment

• Codex Desktop: 26.506.21252
• macOS: 15.7.5, build 24G624
• Architecture: arm64
• Chrome plugin: openai-bundled/chrome 0.1.7
• Google Chrome: 148.0.7778.97
• Codex Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Codex Chrome Extension version: 1.1.4_0

What I tried

From Codex Desktop, using the Chrome plugin runtime:

• Bootstrapped scripts/browser-client.mjs
• Called agent.browsers.get("extension")
• Tried browser.user.openTabs() as a lightweight health check
• Retried once after the first timeout

Both attempts timed out and reset the Node kernel:

js execution timed out; kernel reset, rerun your request

Diagnostics

The plugin-provided diagnostics report that Chrome, the extension, and the native messaging manifest are all OK.

Chrome is running:

{
  "platform": "darwin",
  "running": true
}

Extension check:

{
  "installed": true,
  "registered": true,
  "enabled": true,
  "disabled": false,
  "versions": ["1.1.4_0"],
  "exitCode": 0
}

Native host manifest check:

{
  "exists": true,
  "nameMatches": true,
  "hasExpectedOrigin": true,
  "registryMatchesManifestPath": true,
  "correct": true,
  "problem": null
}

Installed browser check:

{
  "installed_browsers": [
    {
      "name": "Google Chrome",
      "path": "/Applications/Google Chrome.app",
      "version": "148.0.7778.97"
    }
  ]
}

Expected behavior

browser.user.openTabs() should return the list of open Chrome tabs.

Actual behavior

The extension-backed Chrome plugin handshake hangs until timeout, even though Chrome is running, the Codex Chrome Extension is installed/enabled, and the native messaging manifest is correct.

Notes

This has been reproduced multiple times. The failure appears to be in the Codex Desktop <-> Codex Chrome Extension communication path, not in Chrome installation, extension installation, or native host manifest setup.

[github-actions]

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

• Chrome plugin discovery still times out after socket cleanup; extension-host socket does not respond to getInfo #21681
• Chrome plugin installed and enabled, but automation calls time out on Windows #21698
• Chrome plugin setup can hang when unrelated browser-use sockets exist #21672
• Windows Codex Desktop: Chrome plugin and Browser Use setup hang; plugin uninstall fails with os error 5 #21670
• Browser Use setup hangs on Windows when Chrome and IAB pipes are both present #21691

Powered by Codex Action

[jonky0814-spec]

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.

[GritLs]

We are seeing the same issue on macOS with chrome@openai-bundled 0.1.7 and Codex Chrome Extension 1.1.4_0.

Local plugin diagnostics pass:

• Chrome is running.
• Codex Chrome Extension is installed, registered, and enabled.
• Native host manifest exists and is correct.

But the first lightweight Chrome-backed call still hangs:

browser.user.openTabs()
js execution timed out; kernel reset, rerun your request

We also tested after turning off Clash, and the timeout still reproduced, so proxy/TUN is not the only trigger in this case.

One local signal matches the socket-discovery/native-host family of issues: /tmp/codex-browser-use contains multiple sockets; extension-host is attached to one socket, while the Codex process holds several different sockets. So this looks like the same Chrome plugin handshake/socket discovery failure rather than a page-specific problem.

[ZengEric]

Update after today's Codex Desktop update: this is still reproducible.

Current versions:

• Codex Desktop: 26.506.31421
• Chrome plugin: openai-bundled/chrome 0.1.7
• Google Chrome: 148.0.7778.97
• Codex Chrome Extension: 1.1.4_0

Retest details:

• Reset the Node kernel
• Bootstrapped scripts/browser-client.mjs
• Called agent.browsers.get("extension")
• Tried browser.user.openTabs() as the lightweight health check
• Retried the same call once

Both attempts timed out after 45 seconds:

js execution timed out; kernel reset, rerun your request

The plugin-provided diagnostics still pass: Chrome is running, the extension is installed/enabled, and the native host manifest is correct.

[ZengEric]

Additional local narrowing after comparing related issues (#21672, #21704, #21719, #21722):

I tested the socket-cleanup workaround and it did not resolve this reproduction.

What I observed before cleanup:

• /tmp/codex-browser-use contained many socket pathnames.
• Two old extension-host processes from the previous day were still alive and each held an old /tmp/codex-browser-use/*.sock socket.
• The current Codex process held many different browser-use sockets.

What I tried:

1. Killed the two old extension-host processes.
2. Chrome automatically started a fresh extension-host process.
3. Removed all other socket pathnames from /tmp/codex-browser-use, keeping only the fresh extension-host socket.
4. Retried the same Chrome health check:

await setupAtlasRuntime({ globals: globalThis });
globalThis.browser = await agent.browsers.get("extension");
await browser.user.openTabs();

Result: it still timed out after 45 seconds with:

js execution timed out; kernel reset, rerun your request

So this machine did have stale/multiple socket symptoms, but the #21672-style socket cleanup alone did not unblock Chrome setup.

I also checked the ambient network direction from #21704/#21722:

• Shell curl -I https://chatgpt.com/backend-api/me returns HTTP 403 with cf-mitigated: challenge and server: cloudflare.
• In the Codex Node REPL runtime, nodeRepl.fetch("https://chatgpt.com/backend-api/me") hangs until the JS kernel times out.
• nodeRepl.requestMeta contains x-codex-browser-use-available-backends: ["chrome", "iab"], but does not contain x-codex-browser-use-disable-ambient-network: true.

I tried to test the #21722 workaround from inside the current Desktop session, but the runtime does not allow setting it dynamically:

nodeRepl.requestMeta["x-codex-browser-use-disable-ambient-network"] = true
-> Cannot add property x-codex-browser-use-disable-ambient-network, object is not extensible

and replacing globalThis.nodeRepl with a proxy fails too:

Cannot redefine property: nodeRepl

This makes the current reproduction look closer to the #21704/#21722 ambient-network initialization hang than to only stale socket discovery. A supported way to disable or bound the ambient /backend-api/me probe would be useful for validating this fully in Codex Desktop.