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

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

• #21681
• #21698
• #21672
• #21670
• #21691

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.

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.

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.

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.

Related Windows 11 finding from a separate repro:

When Chrome is fully closed, the bundled Chrome plugin can fail before the extension backend is discovered, even if the native host manifest is valid. In that state:

• Chrome running check reports running: false
• extension-host.exe is not running
• browser discovery only returns the in-app browser
• requesting the Chrome-backed backend returns Browser is not available: extension

Opening the selected Chrome profile starts extension-host.exe, the Chrome backend appears in browser discovery, browser.user.openTabs() succeeds, and a smoke navigation to https://example.com/ returns title Example Domain.

Suggested diagnostic improvement: run a lightweight preflight before browser-client setup that checks whether Chrome is running and whether the native host manifest is valid. If Chrome is closed, show a recovery hint to open Chrome with the selected profile before retrying, instead of surfacing the generic unavailable-backend error.

I have a small candidate patch against the bundled Chrome plugin layout that adds this preflight and updates the Chrome skill flow, but the public openai/codex repository does not appear to contain the bundled Chrome plugin source files, so I cannot open a valid PR against this repo for that patch.

I checked the repository contribution guidance before opening a PR. The documented process says external PRs are by invitation only, and that analysis plus a high-level fix outline should go in the issue thread first.

Candidate fix shape:

1. Add a small Chrome backend preflight script to the bundled Chrome plugin package.
2. Have it run before browser-client setup on the first Chrome-backed task.
3. Check only non-private prerequisites:

• whether Chrome is running
• whether the native messaging host manifest exists and is valid

1. If Chrome is closed, return a structured problem such as chrome_not_running with a recovery hint to open Chrome with the selected profile before retrying.
2. Preserve existing diagnostics for missing or invalid native host setup.

I tested this approach locally against the bundled Chrome plugin layout:

• normal current-machine preflight returns ok: true when Chrome is running and the native host manifest is valid
• simulated missing native host manifest returns structured native_host_invalid output instead of throwing
• the closed-Chrome failure mode is avoided before browser-client setup, which prevents the generic Browser is not available: extension message from being the first actionable signal

Patch summary:

• adds scripts/check-backend-preconditions.js
• updates skills/chrome/SKILL.md to run the preflight before browser-client bootstrap
• handles diagnostic script exit code 1 as structured JSON rather than treating it as a runtime failure

I did not open a PR against openai/codex because this repository does not appear to contain the bundled Chrome plugin source paths changed by the patch. If a maintainer confirms the correct source location or invites a PR here, I can prepare the branch against the right target and include the exact patch.