Chrome/browser-use setupAtlasRuntime can hang when ambient /backend-api/me probe does not complete

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

• #21681
• #21698
• #21672
• #21371

Powered by Codex Action

Follow-up after testing the suggested duplicate workarounds:

I do not think this issue should be closed as a duplicate of the current suggestions yet.

What I tested:

• #21672 socket cleanup workaround: reproduced the precondition locally with many /tmp/codex-browser-use/*.sock candidates plus one extension-host socket. I removed all non-extension socket pathnames so that only the extension-host candidate remained, then retried Chrome setup. setupAtlasRuntime() still timed out after cleanup. So the #21672 workaround does not resolve this case.
• #21681 extension-host getInfo hypothesis: I connected directly to the remaining extension-host socket using the same framed JSON-RPC protocol. ping returned "pong", and getInfo returned name: "Chrome" / type: "extension" promptly. So this case does not match “extension-host socket does not respond to getInfo”.
• #21698 Windows Chrome timeout: the local Chrome/extension/native-host checks pass, so this only matches the broad symptom, not the observed layer.
• #21371 / #19314 Windows app-server path workaround: not applicable here. codex app-server --help works, and nodeRepl.homeDir is a string rather than null.

Additional checks:

• I tested the ChatGPT backend probes across several available egress modes. https://chatgpt.com/backend-api/me consistently returned HTTP 403 HTML instead of the expected JSON; most modes included cf-mitigated: challenge, and one mode returned plain 403 HTML. In that plain-403 mode, direct nodeRepl.fetch("https://chatgpt.com/backend-api/me") still timed out, and Chrome setup still timed out.
• The extension backend itself is reachable, but the setup path still hangs when the ambient ChatGPT backend probe is involved.

Current state:

• The Chrome extension-host socket responds to direct protocol probes.
• Chrome plugin setup still times out.

This suggests a narrower failure mode than the duplicate candidates: setupAtlasRuntime() starts or depends on ambient network work that calls ChatGPT backend endpoints, and when those endpoints return challenge/HTML or otherwise do not complete through nodeRepl.fetch, setup can hang instead of fast-failing and continuing with the reachable Chrome extension backend.

A fix that would likely address this case would be one of:

• make the ambient ChatGPT backend probes bounded and non-blocking for browser setup,
• fast-fail on non-JSON/HTML/403/challenge responses from those probes, or
• avoid starting the ambient /backend-api/me probe during extension backend discovery unless it is strictly required.

I am seeing a closely related Windows reproduction.

Feedback / correlation ID from Codex /feedback:

019e07a5-6cad-75a2-91fb-2bf1f7989050

Environment:

OS: Windows 11 / Windows build 10.0.26200
Codex App: Windows Store build 26.506.21252
Bundled codex-cli: 0.129.0-alpha.15
Chrome: 147.0.7727.138
Codex Chrome plugin: openai-bundled chrome 0.1.7
Codex Chrome Extension: 1.1.4_0
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Chrome profile: Default

Initial failure:

Calling the Chrome browser backend to list open tabs timed out repeatedly. browser.user.openTabs() never returned; the Node REPL eventually reported:

js execution timed out; kernel reset, rerun your request

Initial local diagnostics showed that the Chrome extension itself was installed and enabled in the Default Chrome profile, but the Windows native messaging registry key was missing:

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

The manifest already existed at:

C:\Users\<username>\AppData\Local\OpenAI\extension\com.openai.codexextension.json

Manual repair performed:

I manually added the HKCU native messaging host registry key pointing to the manifest path. After that, the bundled plugin check passed:

check-native-host-manifest.js --json -> correct: true

Current state after repair and restarts:

check-native-host-manifest.js: correct=true
check-extension-installed.js: installed=true, registered=true, enabled=true
Chrome launches extension-host.exe
extension-host.exe command line includes:
  chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/
Restarted Chrome
Restarted Codex App

Even after this, Chrome/browser-use still hangs during browser-client setup / openTabs. The visible failure remains a JS execution timeout before any useful browser tab operation completes.

Additional observation:

There were multiple codex-browser-use* named pipes present. I also tried a diagnostic run that only allowed the current Chrome host pipe to be seen by browser-client.mjs; setup still timed out. I also tried a run that only allowed non-Chrome browser-use pipes; setup still timed out. This makes the remaining issue look less like a Chrome profile / extension install / registry problem, and more like a browser-use native pipe bridge or setup handshake hang.

Expected:

Once the Chrome extension is installed/enabled, the native messaging manifest is correct, and Chrome is able to start extension-host.exe, setupAtlasRuntime() / browser.user.openTabs() should either work or fail fast with a clear diagnostic.

Actual:

The call hangs until the JS execution timeout resets the kernel.

For visibility, I think this new Windows reproduction is pointing to the same solution direction I proposed earlier here:

https://github.com/openai/codex/issues/21704#issuecomment-4405214603

And the new reproduction is here:

https://github.com/openai/codex/issues/21704#issuecomment-4406906316

The important point is that this should probably not be treated as only another user-side Chrome profile / extension / registry repair issue. In the Windows reproduction, the native messaging manifest is already correct after repair, the extension is installed/enabled, and Chrome is able to start extension-host.exe, but setupAtlasRuntime() / browser.user.openTabs() still hangs until the JS execution timeout.

So I think the fix should focus on making the browser setup path resilient to the ambient ChatGPT backend probe / setup handshake path:

1. make the ambient ChatGPT backend probes bounded and non-blocking for browser setup;
2. fast-fail on non-JSON / HTML / 403 / Cloudflare challenge responses from those probes;
3. avoid starting the ambient /backend-api/me probe during extension backend discovery unless it is strictly required.

In other words, once the extension backend is reachable, browser setup should continue or fail fast with a clear diagnostic instead of being blocked by unrelated ambient backend/network work. Please refer to the proposed solution direction in my earlier comment above.

I can reproduce what looks like the same failure mode on Windows.

Environment

• OS: Windows
• Codex Desktop / CLI shown in logs: 0.130.0-alpha.5
• Browser Use / IAB: 26.506.31421
• Chrome plugin: chrome@openai-bundled 0.1.7
• Codex Chrome Extension: 1.1.4_0
• Chrome: 147.0.7727.139
• Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Proxy: local xray proxy at 127.0.0.1:10808

What I observed

The official Chrome plugin initialization hangs at:

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

It eventually times out with the Node REPL kernel reset.

The Chrome-side diagnostics pass:

• chrome-is-running.js --json: Chrome is running
• check-extension-installed.js --json: extension installed, registered, enabled
• check-native-host-manifest.js --json: manifest is correct
• Direct JSON-RPC probing of the \\.\pipe\codex-browser-use... pipe returns getInfo successfully with Chrome extension info

So the Chrome extension/native-host/pipe path itself appears healthy.

Important diagnostic

nodeRepl.fetch("https://chatgpt.com/backend-api/me") hangs in the same environment, while normal browser access to ChatGPT works. Command-line probes to ChatGPT/backend API endpoints can hit Cloudflare challenge behavior, which seems consistent with this issue's ambient network hypothesis.

When I inject the existing metadata flag before loading browser-client.mjs:

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

then run the normal initialization path again, setupAtlasRuntime({ globals: globalThis }) completes quickly, agent.browsers.get('extension') works, and Chrome can be controlled normally.

I did not need to modify browser-client.mjs. In fact, modifying that file breaks trust and causes:

privileged native pipe bridge is not available; browser-client is not trusted

Expected fix

I agree with the suggested direction here: ambient network/account/telemetry initialization should not be able to block Chrome backend discovery indefinitely. It should fail open, have a short timeout, or expose a supported setting for x-codex-browser-use-disable-ambient-network.

For anyone affected, here is the short-term prompt I send to Codex before using @chrome in my environment.

This is only a local diagnostic/workaround prompt, not an official fix:

Before using `@chrome`, temporarily set these properties in Node REPL:

Object.getPrototypeOf(nodeRepl.requestMeta)["x-codex-browser-use-disable-ambient-network"] = true
Object.getPrototypeOf(nodeRepl.requestMeta)["x-codex-browser-use-security-mode"] = "disabled-for-local-testing"

Then use the real Chrome plugin / Chrome skill path. Do not modify `browser-client.mjs`.

After the Chrome work is done, delete both properties from `Object.getPrototypeOf(nodeRepl.requestMeta)`.

Only visit websites I explicitly ask you to visit. Do not read cookies, passwords, localStorage, session storage, or other sensitive browser storage.

In my case, this lets setupAtlasRuntime({ globals: globalThis }) complete and allows agent.browsers.get("extension") to control the real Chrome backend.

Again, I think the product fix should be to make the ambient backend / site-status network probes fail fast or degrade safely, rather than requiring users to inject request metadata manually.

One additional data point from local verification: the bundled Chrome skill now appears to carry this workaround in its bootstrap template by setting x-codex-browser-use-disable-ambient-network before setupAtlasRuntime().

That is useful as a call-site mitigation, but I do not think it closes the underlying issue.

Why:

• the workaround is effective when callers go through the updated skill bootstrap;
• but any path that directly imports and calls browser-client.mjs without injecting that metadata can still reproduce the same hang;
• so the product/runtime bug still appears to be that ambient network initialization can block Chrome backend setup instead of failing fast or degrading safely.

So from my side, this issue still looks valid even if the bundled skill now includes a mitigation. The durable fix still seems to be one of:

1. bound the ambient /backend-api/me probe with a short timeout;
2. treat probe failure as recoverable for Chrome backend discovery where safe; or
3. expose a supported setting for disabling ambient network bootstrap instead of requiring an internal request-metadata flag.

One follow-up that may be useful for others hitting this issue: I published a small local wrapper skill example here:

https://github.com/JaisingZ/chrome-local-skill

This is not an upstream fix and it does not replace the official chrome@openai-bundled plugin.

What it does:

• keeps the workaround in a user-managed skill under ~/.codex/skills
• sets x-codex-browser-use-disable-ambient-network before Chrome bootstrap
• then continues to use the real bundled Chrome backend

Why this is useful:

• editing the bundled Chrome skill or marketplace/cache copies is fragile and gets overwritten by Codex / plugin upgrades
• this wrapper gives a stable local entry point for environments where the ambient network bootstrap hang is reproducible
• it avoids modifying browser-client.mjs, which would break trust

So this repo is mainly a persistence / operability workaround for affected users, not a substitute for the product fix discussed above.

I still think the real fix should be in the product/runtime layer:

• bound the ambient /backend-api/me probe with a short timeout
• fail open or degrade safely when that probe fails
• or expose a supported setting instead of requiring an internal request-metadata flag

Possibly related diagnostic from Chromebook / Crostini Linux:

For chatgpt.com/backend-api/* requests from the same environment and network, I observed User-Agent-dependent Cloudflare behavior:

• no explicit/browser-like User-Agent: HTTP 403 with cf-mitigated: challenge
• Chrome-like User-Agent: HTTP 401 without cf-mitigated: challenge

So in my environment, non-browser HTTP requests to backend-api can be challenged by Cloudflare, but a browser-like User-Agent changes the result enough to reach the application layer.

This may be relevant to the ambient /backend-api/me probe described here, although I am not specifically reproducing the browser-use setupAtlasRuntime hang.