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

Open 💬 5 comments Opened May 9, 2026 by 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.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗