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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   browser

   on May 8, 2026
2. github-actions commented on May 8, 2026

   

   github-actionsbot

   on May 8, 2026 – with GitHub Actions

   Contributor

   More 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
3. caaaptaintop commented on May 8, 2026

   

   caaaptaintop

   on May 8, 2026

   More actions

   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.
4. GritLs commented on May 8, 2026

   

   GritLs

   on May 8, 2026

   More actions

   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.
5. ZengEric commented on May 9, 2026

   

   ZengEric

   on May 9, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   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.
6. ZengEric commented on May 9, 2026

   

   ZengEric

   on May 9, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   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.
7. GodsBoy commented on May 18, 2026

   

   GodsBoy

   on May 18, 2026

   More actions

   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.
8. GodsBoy commented on May 18, 2026

   

   GodsBoy

   on May 18, 2026

   More actions

   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
   4. 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.
   5. 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.
9. etraut-openai

   marked Codex Desktop Chrome plugin connection times out despite extension and native host checks passing #21851 as a duplicate of this issue on Aug 6, 2026