Codex Desktop Chrome plugin times out at setupAtlasRuntime on Windows despite extension/native host checks passing

[dozeeexx]

Summary

Codex Desktop Chrome plugin (chrome@openai-bundled) cannot open/control Chrome. The plugin appears installed and enabled, but browser runtime initialization hangs until timeout at setupAtlasRuntime.

Environment

• OS: Windows
• Codex Desktop: OpenAI.Codex_26.506.3741.0_x64
• Model in session: GPT-5.5
• Chrome: 148.0.7778.97
• Codex Chrome Extension: 1.1.4_0
• Chrome plugin cache: C:\Users\Administrator\.codex\plugins\cache\openai-bundled\chrome\0.1.7
• Native host exe: C:\Users\Administrator\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

User-visible issue

Request: @chrome 打开谷歌

Expected: Codex opens Google in the user's Chrome via the Chrome plugin.

Actual: The Chrome plugin call times out. The runtime does not return an actionable error.

Diagnostics performed

All official plugin diagnostic scripts pass when run outside the sandbox:

chrome-is-running: running=true
installed-browsers: Google Chrome installed, version 148.0.7778.97
check-extension-installed: installed=true, registered=true, enabled=true, version=1.1.4_0
check-native-host-manifest: correct=true, registryMatchesManifestPath=true, hasExpectedOrigin=true

Current session metadata includes Chrome backend:

"x-codex-browser-use-available-backends": ["chrome", "iab"]

Native host process is created and exposes pipes, for example:

extension-host.exe running
chrome.nativeMessaging.in.* / out.* pipes exist
codex-browser-use\\<uuid> pipe exists and is owned by extension-host.exe

However, invoking the Chrome plugin bootstrap hangs until the Node REPL tool timeout resets the kernel:

const { setupAtlasRuntime } = await import('file:///C:/Users/Administrator/.codex/plugins/cache/openai-bundled/chrome/0.1.7/scripts/browser-client.mjs');
await setupAtlasRuntime({ globals: globalThis });

Observed result:

js execution timed out; kernel reset, rerun your request

Recovery attempts

• Opened selected Chrome profile with scripts/open-chrome-window.js.
• Verified extension/native-host manifest is correct.
• Killed stale extension-host.exe and native messaging cmd.exe processes.
• Relaunched Chrome profile and verified new native-host process and new pipes were created.
• Retried plugin bootstrap multiple times.
• Fully closed Chrome/native-host to unblock plugin uninstall; Chrome extension immediately relaunched native host when Chrome restarted.

The plugin still times out at initialization.

Suspected bug

The Chrome plugin/native-host bridge can reach a state where install diagnostics pass and native-host pipes exist, but setupAtlasRuntime never completes or reports a specific failing backend. The product should either recover, skip stale/unresponsive pipes with bounded per-pipe timeout, or surface a concrete native-host/protocol error instead of hanging until tool timeout.

Impact

@chrome is unusable on this Windows Codex Desktop installation even though Codex reports the Chrome extension as installed and connected.

[github-actions]

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

• Codex Desktop Chrome plugin hangs during extension backend bootstrap/openTabs on Windows #21765
• Chrome plugin installed and enabled, but automation calls time out on Windows #21698
• Browser Use setup hangs on Windows when Chrome and IAB pipes are both present #21691
• Windows Codex Desktop: Chrome plugin and Browser Use setup hang; plugin uninstall fails with os error 5 #21670
• Codex Desktop Chrome plugin connection times out despite extension and native host checks passing #21851

Powered by Codex Action

[Ji-kuai]

Adding another Windows data point with one extra diagnostic detail that may help narrow this down.

Environment observed:

• Windows
• Chrome plugin cache version: chrome@openai-bundled 0.1.7
• Codex Chrome Extension: 1.1.4_0
• Chrome: 148.0.7778.96
• check-extension-installed.js --json: installed, registered, enabled
• check-native-host-manifest.js --json: correct, expected origin present, registry points to the manifest
• Chrome can launch extension-host.exe; chrome.nativeMessaging.in/out.* pipes appear

User-visible behavior:

• Official @chrome / setupAtlasRuntime({ globals }) path hangs until the tool timeout, typically around 120s.
• When Chrome is not running, the same path can fail faster with Browser is not available: extension, which suggests the hang happens after the Chrome backend exists and is being discovered/initialized.

Additional low-level observation:

• Direct JSON-RPC probing of the Chrome codex-browser-use\\... named pipe succeeds quickly.
• getInfo returns a Chrome extension backend (name: Chrome, version: 1.1.4, type: extension).
• getUserTabs with the current session metadata returns the current Chrome tab list successfully.

So in this case the Chrome extension and native host are alive, and the underlying pipe can answer basic requests. The failure appears to be in the higher-level browser-client backend discovery/selection/wrapping path rather than in Chrome, the extension install, or the native host manifest.

Also worth noting: locally editing scripts/browser-client.mjs is not a viable workaround. After modifying that bundled file, the runtime reports that the browser client is not trusted and loses access to the privileged native pipe bridge. Restoring the original file restores normal import behavior, but the original initialization timeout remains.

[Jameschunxiao]

Adding another Windows data point that matches this issue.

Environment observed:

• OS: Windows
• Chrome plugin cache: openai-bundled/chrome 0.1.7
• Codex Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Codex Chrome Extension version: 1.1.4_0
• Google Chrome: 148.0.7778.97

Health checks pass:

• chrome-is-running.js --check: Chrome running: yes
• check-extension-installed.js --json: installed/registered/enabled all true, disabled false, exitCode 0
• check-native-host-manifest.js --json: manifest exists, registry key matches, expected origin present, correct: true, problem: null

Failure:

• Importing scripts/browser-client.mjs succeeds.
• Calling setupAtlasRuntime({ globals: globalThis }) consistently times out after 90-120s.
• Opening a fresh Chrome window, reinstalling the Chrome extension, restarting Chrome, and restarting Codex did not resolve it.

Observed error:

tool call error: tool call failed for `node_repl/js`
Caused by:
    timed out awaiting tools/call after 120s

Impact:

• Chrome can open normal websites, including Google/Facebook, but Codex cannot control authenticated Chrome tabs.
• This blocks browser automation for Facebook, Search Console, and other logged-in business tools.

This looks like the same class of issue: extension and native host diagnostics are healthy, but the Chrome plugin bridge/runtime initialization hangs.