›_ Codex Issues
Codex Issues / #21851

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

Open 💬 6 comments Opened May 9, 2026 by Lfish010
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop cannot connect to the Chrome plugin. The Chrome extension and native messaging host checks both report a healthy setup, but the browser runtime initialization consistently times out before any tab access can occur.

What I was trying to do

Use the Codex Chrome plugin to search for 海明威 in Chrome.

Observed behavior

Repeated attempts to initialize the Chrome browser runtime time out at:

await setupAtlasRuntime({ globals: globalThis });

The timeout happens before calls such as:

await agent.browsers.get("extension");
await browser.user.openTabs();

So the failure appears to be in the Chrome extension/runtime handshake layer, not in page navigation or search.

Troubleshooting already attempted

  • Reinstalled / repaired the Codex Chrome plugin from the Codex plugin UI
  • Fully quit and reopened Chrome
  • Restarted the computer
  • Retried the Chrome connection multiple times with longer timeouts
  • Confirmed Chrome is running
  • Confirmed the Codex Chrome Extension is installed and enabled
  • Confirmed the native messaging host manifest exists and appears correct

Diagnostic results

Chrome running check

Google Chrome running: yes
process: Google Chrome

Extension check

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

Native host manifest check

{
  "manifestPath": "/Users/liuxiancong/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json",
  "expectedHostName": "com.openai.codexextension",
  "actualHostName": "com.openai.codexextension",
  "hasExpectedOrigin": true,
  "correct": true,
  "problem": null
}

Additional issue

The plugin helper script for opening a Chrome window also fails:

Command failed: open -n -a /Applications/Google Chrome.app --args --profile-directory=Default --new-window about:blank
The application /Applications/Google Chrome.app cannot be opened for an unexpected reason,
error=Error Domain=NSOSStatusErrorDomain Code=-10827 "kLSNoExecutableErr: The executable is missing"

However, Chrome itself is installed and running, and the browser check reports:

Google Chrome
version: 148.0.7778.96
path: /Applications/Google Chrome.app

Environment

  • macOS
  • Chrome version: 148.0.7778.96
  • Codex Chrome Extension version: 1.1.4_0
  • Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Chrome profile detected by checks: Default
  • Chrome app path reported by checks: /Applications/Google Chrome.app

Expected behavior

Codex should be able to establish a connection to the Chrome extension, read open tabs, and perform browser automation tasks.

Actual behavior

Chrome runtime initialization consistently times out even though extension and native host checks pass.

Suggested investigation areas

  • Whether setupAtlasRuntime can hang indefinitely during native messaging or extension handshake when checks appear healthy
  • Whether the failure path can emit a clearer diagnostic instead of only timing out
  • Whether open-chrome-window.js is using a macOS Chrome launch path or invocation pattern that can fail with kLSNoExecutableErr despite Chrome being installed and running

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

  • #21705
  • #21719
  • #21681
  • #21704

Powered by Codex Action

kuigoo · 2 months ago

If you use a VPN, try turning on TUN mode.

Ztomepic · 2 months ago
If you use a VPN, try turning on TUN mode.

This works. Thank you.

AndyFu12306 · 2 months ago

I’m seeing a closely related failure on macOS after reinstalling the Codex Chrome plugin/extension. The installation checks all pass, but the Chrome backend remains unstable, especially around remote page navigation/control.

Environment observed:

  • macOS, Apple Silicon
  • Google Chrome: 148.0.7778.168
  • Chrome plugin files: openai-bundled/chrome 0.1.7
  • Codex Chrome Extension: 1.1.4_0
  • Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Chrome profile: Default

Checks that pass:

  • Chrome is running
  • Extension is installed, registered, enabled, not disabled
  • Native messaging host manifest exists and is correct
  • Manifest origin matches chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/
  • Native host binary exists and is signed

Repro/observations:

  1. After opening a fresh Chrome window, lightweight backend communication can recover briefly.
  2. browser.user.openTabs() succeeded 10/10 times in one short run, usually returning in 1-3 ms.
  3. A local page served from 127.0.0.1 works normally through the Chrome backend:
  • tab.goto(localhost) succeeds
  • DOM/text read succeeds
  • click succeeds
  • screenshot succeeds
  1. Remote page navigation still hangs/resets the runtime:
  • tab.goto("https://example.com/") timed out after 30s and reset the JS kernel
  • the Chrome tab remained at about:blank
  1. Bilibili popular page reproduces the same class of failure:
  • tab.goto("https://www.bilibili.com/v/popular/all") times out
  • title/URL reads can work after claiming an already-open tab
  • DOM evaluate, screenshot, and coordinate click on that page time out/reset
  1. After these failed remote-page/control attempts, cleanup sometimes fails with:
  • native pipe closed before response
  1. Subsequent attempts may fail with:
  • Browser is not available: extension
  1. The recovery helper opens a new about:blank window, but when the native pipe is broken, cleanup cannot close it, leaving blank tabs behind.

The important boundary is that local-page control works, while remote-page goto/page-control hangs and can break the native pipe. That makes this look less like a Chrome extension installation issue and more like a Chrome backend/browser-use/native-pipe/app-server runtime issue triggered by remote navigation/control.

Reinstalling the Codex Chrome plugin/extension did not fix it; it changed the extension instance ID and restored communication briefly, but the same remote navigation/control failures came back.

centry4sangchu · 1 month ago

Related but slightly different reproduction from Windows / UK: #24969

In my case the Chrome extension/native host is not merely timing out; the app UI itself disables Google Chrome under Computer use with:

Disabled by your organization or unavailable in your region

Local checks:

  • Extension installed/enabled.
  • Native host manifest correct.
  • Extension local state says native host connected.
  • Local Codex feature flags include computer_use=true and browser_use_external=true.
  • Active runtime still exposes only IAB; Chrome/extension backend unavailable.

This may be connected to remote-page/Chrome backend instability, but the first-order problem appears to be Chrome/Computer Use availability/provisioning being disabled before the backend can be used.

johnsilvavlogs · 7 days ago

Additional macOS evidence that separates two failure classes which can otherwise both surface as “Chrome unavailable” or -10827.

Environment:

  • macOS 26.5.2 (25F84), Apple Silicon
  • Codex Desktop 26.707.61608 (build 5200)
  • Google Chrome 149.0.7827.201
  • Codex Chrome extension and native-host manifest checks passed

1. Signed-bundle metadata detritus

The installed Chrome bundle had 66 empty-looking com.apple.FinderInfo attributes under signed paths. codesign --verify --deep --strict rejected it as signed-code detritus. Removing only those attributes restored strict signature validation and Gatekeeper acceptance; three fresh Chrome-plugin bindings then selected the extension and listed tabs successfully.

Controlled comparison:

  • The official mounted Chrome DMG source had zero FinderInfo/ResourceFork paths and passed strict verification.
  • Fresh cp -R and ditto copies also had zero and passed strict verification.
  • Injecting FinderInfo on the same framework-relative path in an isolated copy reproduced the strict signature failure.

This proves a post-source metadata writer is sufficient, but the historical writer was not preserved. I cannot attribute it to Google, Codex, Finder, or a particular copy/update command. It is still a useful diagnostic before interpreting kLSNoExecutableErr literally.

2. Troubleshooting-helper execution-surface mismatch

The bundled Chrome troubleshooting docs say to use node_repl, but directly importing open-chrome-window.js there is denied at its node:process import before main() or open runs. Invoking the same bundled script through a host command surface succeeds against the now-healthy Chrome installation.

Therefore the direct-import denial cannot itself produce LaunchServices -10827; a historical -10827 belongs to a distinct host/external launch path. This is adjacent to the broader macOS GUI-launch sandbox boundary in #30043.

Requested product fixes:

  1. Document or broker the supported execution surface for bundled troubleshooting CLI scripts separately from browser-client use in node_repl.
  2. Distinguish restricted-runtime/module-policy denial, LaunchServices sandbox denial, signature detritus, and a genuinely missing executable in diagnostics.
  3. On extension transport failure, recommend a fresh task/runtime canary before cache/profile repair so a task-local closed transport is not reported as a global Chrome outage.

Local workaround used here was to preserve the runtime restrictions, validate strict signing/Gatekeeper plus targeted FinderInfo/ResourceFork state, and run only the exact bundled troubleshooting CLI through an allowed host command surface. No Chrome profile, extension, native host, or signed app was patched.