Skip to content

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

Open
Open
Codex Desktop Chrome plugin times out at setupAtlasRuntime on Windows despite extension/native host checks passing#21878
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)windows-osIssues related to Codex on Windows systems

Description

@dozeeexx
dozeeexx
opened on May 9, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    browser
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on May 9, 2026

  2. github-actions commented on May 9, 2026

    @github-actions
    github-actionsbot
    on May 9, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. Ji-kuai commented on May 11, 2026

    @Ji-kuai
    Ji-kuai
    on May 11, 2026 – with ChatGPT Codex Connector

    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.

  4. Jameschunxiao commented on May 12, 2026

    @Jameschunxiao
    Jameschunxiao
    on May 12, 2026 – with ChatGPT Codex Connector

    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.

  5. htazq commented on May 14, 2026

    @htazq
    htazq
    on May 14, 2026 – with ChatGPT Codex Connector

    Adding another Windows reproduction with the same failure mode, plus a couple of local IPC observations that may help narrow it down.

    Environment

    • OS: Windows 11 Pro for Workstations, 10.0.26200, x64
    • Codex Desktop package path includes: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
    • Codex product version: 26.506.31421
    • Chrome plugin: chrome@openai-bundled 0.1.7
    • Chrome: 148.0.7778.97
    • Codex Chrome Extension: 1.1.4_0
    • Thread metadata advertises browser backends: ["chrome", "iab"]

    User-visible failure

    A simple request such as:

    @chrome open Google and search for weather

    never reaches page navigation. The browser-client bootstrap hangs until the Node REPL execution timeout resets the kernel.

    Observed with:

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

    Result:

    js execution timed out; kernel reset, rerun your request

    Retrying with a fresh Chrome window opened by scripts/open-chrome-window.js also timed out after 120s.

    Checks that pass

    The plugin diagnostic scripts report the install is healthy:

    installed-browsers.js --check: Google Chrome installed, version 148.0.7778.97
check-extension-installed.js --json: installed=true, registered=true, enabled=true, versions=["1.1.4_0"]
check-native-host-manifest.js --json: exists=true, nameMatches=true, hasExpectedOrigin=true, registryMatchesManifestPath=true, correct=true

    The native host manifest points to:

    %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

    and the bundled host binary path under:

    %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

    Additional IPC/process observations

    At one point, after Chrome was no longer listed as running, there were still multiple extension-host.exe processes and native messaging pipes present. A later snapshot showed:

    chrome-is-running.js --check: Google Chrome running: no
extension-host.exe: still running from the chrome plugin cache path
chrome.nativeMessaging.out.* pipe: present
codex-browser-use* pipe count: 62

    Examples of the browser-use pipe pattern observed:

    \\.\pipe\codex-browser-use-<uuid>
\\.\pipe\codex-browser-use\<uuid>

    This may be a useful difference from a clean startup: the runtime appears to scan/connect many candidate codex-browser-use* pipes, and setupAtlasRuntime does not return or fail fast if one or more candidates are stale/unresponsive.

    Network observation

    A direct non-browser probe from the machine to the ambient account endpoint returns a Cloudflare challenge:

    HEAD https://chatgpt.com/backend-api/me
status=403
server=cloudflare
cf-mitigated=challenge

    This may relate to #21704, but in this Windows reproduction there are also many stale-looking local browser-use/native-host IPC resources, so I would not assume this is only network-related.

    Expected behavior

    Even if some backend pipes are stale/unresponsive, Chrome/browser-use setup should either skip them with a bounded per-pipe timeout or fail with a concrete diagnostic. The current failure is an outer tool timeout with no actionable browser/plugin error.

  6. Ji-kuai commented on May 15, 2026

    @Ji-kuai
    Ji-kuai
    on May 15, 2026 – with ChatGPT Codex Connector

    Follow-up to my earlier Windows data point: I was able to validate a non-file-modifying workaround for this failure mode.

    In this environment, direct nodeRepl.fetch("https://chatgpt.com/backend-api/me") hangs until the JS execution timeout resets the kernel. That matches the ambient network bootstrap hypothesis from #21704 / #21722.

    Before importing the bundled Chrome browser-client.mjs, I temporarily injected the existing request metadata flag into the current Node REPL runtime:

    const key = "x-codex-browser-use-disable-ambient-network";
Object.defineProperty(Object.getPrototypeOf(nodeRepl.requestMeta), key, {
  value: true,
  configurable: true
});

    Then I used the normal official Chrome plugin path:

    const { setupAtlasRuntime } = await import("file:///.../.codex/plugins/cache/openai-bundled/chrome/0.1.7/scripts/browser-client.mjs");
await setupAtlasRuntime({ globals: globalThis });
globalThis.browser = await agent.browsers.get("extension");

    Result:

    • setupAtlasRuntime() completed immediately instead of timing out.
    • The selected backend was the real Chrome extension backend (name: Chrome, type: extension).
    • A new Chrome tab could be created and navigated to https://www.google.com/; the page title returned Google.
    • No bundled plugin files were modified. Earlier testing confirmed that editing browser-client.mjs breaks trust and causes the privileged native pipe bridge to be unavailable.

    One caveat: if Chrome is fully closed, this workaround changes the failure from a long timeout into a fast Browser is not available: extension error. Starting Chrome manually, then retrying the same runtime metadata injection + official setup path, works. The bundled open-chrome-window.js can also launch Chrome in this environment, but it may not return cleanly even though chrome.exe and extension-host.exe are started.

    So the most practical short-term workaround for affected users appears to be a small local wrapper skill or bootstrap prompt that sets x-codex-browser-use-disable-ambient-network before calling the official Chrome plugin. The product fix should still be in the runtime: bound/fail-open the ambient /backend-api/me probe or expose a supported setting for this flag.

  7. etraut-openai
    marked Windows Chrome plugin hangs in setupAtlasRuntime despite extension/native host checks passing #22462 as a duplicate of this issue on Aug 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)windows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions