Windows Codex Desktop: Chrome plugin and Browser Use setup hang; plugin uninstall fails with os error 5

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

• #21530
• #21597
• #21598

Powered by Codex Action

I can reproduce the Browser Use / Chrome setup hang on Windows with a slightly narrower diagnostic that may help isolate it.

Environment from my repro:

OS: Windows 11 Professional 10.0.26100 x64
Codex Desktop: OpenAI.Codex_26.506.2212.0_x64__2p2nqsd0c76g0
Codex CLI: 0.98.0
Chrome plugin: openai-bundled/chrome/0.1.7
Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha2
Codex Chrome Extension: 1.1.4
Chrome: 147.0.7727.138
Default browser: ChromeHTML

setupAtlasRuntime({ globals: globalThis }) hangs from both plugin client paths:

// chrome@openai-bundled
await setupAtlasRuntime({ globals: globalThis });

// browser-use@openai-bundled
await setupAtlasRuntime({ globals: globalThis });

Both time out after the Node REPL tool timeout and reset the kernel.

However, direct named-pipe JSON-RPC probes using the same 4-byte length-prefixed protocol used by browser-client.mjs return quickly. With the current session_id and turn_id:

\\.\pipe\codex-browser-use-406bfa7d-... -> getInfo returns error: Browser session does not belong to this IAB pipe
\\.\pipe\codex-browser-use-ad0e5497-... -> getInfo returns Codex In-app Browser, version 26.506.21252, type iab
\\.\pipe\codex-browser-use\1f89dc38-... -> getInfo returns Chrome, version 1.1.4, type extension

Direct RPC to the Chrome extension pipe also works:

method=getUserTabs -> result=[] in ~37ms

So in this repro the Chrome extension/native host and the Browser Use backend pipes are alive and responsive; the hang appears to be inside the official setupAtlasRuntime() initialization path after/beyond the raw getInfo pipe responses.

I filed #21691 with these details before noticing this issue. Closing that one as a duplicate and leaving this diagnostic here.

the os error 5 + EPIPE + setupAtlasRuntime hang are probably one bug, not three. windows holds file handles past process exit until handle gc, so if a previous bridge host didn't shut down cleanly the plugin cache stays locked and the next setupAtlasRuntime call wedges on the manifest read. both chrome and IAB backends go through the same native pipe bridge, so they share the lock and both hang the same way. before restarting codex, check task manager for orphaned host processes from the prior session. the 120s timeout is hiding which mutex is stuck, not the actual fault, so cleaner shutdown ordering on the bridge side would surface the real error fast.

Additional local diagnostic after updating/reinstalling Chrome plugin.

Environment now:

Codex Desktop package: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
Codex app reported version in process args: 26.506.31421
Chrome plugin: openai-bundled/chrome/0.1.7
Codex Chrome Extension: 1.1.4
Chrome: 147.0.7727.139
Turn metadata backends: ["chrome", "iab"]
Config currently includes: [windows] sandbox = "unelevated"

The user-level @chrome list open Chrome tab titles path still failed/hung earlier with tool call failed for node_repl/js / timed out awaiting tools/call after 120s.

I then reproduced Boboo-Zhao's lower-level diagnostic on the same running session by bypassing setupAtlasRuntime() and sending JSON-RPC directly over the Windows named pipes using the same 4-byte length-prefixed framing.

Results, with private tab URLs/titles redacted:

Found 6 codex-browser-use pipes.

\\.\pipe\codex-browser-use\88529ba7-... -> getInfo ok in 32ms
  result: { name: "Chrome", version: "1.1.4", type: "extension", extensionId: "hehggadaopoacecdllhhajmbjkdcmajg" }

same Chrome extension pipe -> getUserTabs ok in 2ms
  result: 8 tabs returned

\\.\pipe\codex-browser-use-72b03324-... -> getInfo ok in 1ms
  result: { name: "Codex In-app Browser", version: "26.506.31421", type: "iab", codexSessionId matched current session }

Other pipes either closed without response or returned "Browser session does not belong to this IAB pipe".

So on this machine the Chrome extension/native messaging host is alive and responsive, and the IAB backend is also alive. The failure is still above the raw pipe layer, consistent with the hypothesis that the official setupAtlasRuntime() / browser discovery or bridge initialization path is hanging.

One extra environment detail: I still see a separate old runtime process from another integration:

C:\Tools\codex\codex.exe app-server --listen stdio://

That may be unrelated, because the direct pipe RPC succeeds against the current session, but it is present and could be relevant if stale runtimes/handles affect discovery.

Follow-up after trying the official troubleshooting direction and changing Windows sandbox to elevated.

Current local state after restart:

[windows]
sandbox = "elevated"

Codex Desktop package: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
Codex app reported version in process args: 26.506.31421
Chrome plugin: openai-bundled/chrome/0.1.7
Codex Chrome Extension: 1.1.4
Chrome UI in Codex Settings > Computer Use > Google Chrome shows Connected.
Turn metadata still advertises: ["chrome", "iab"]

User-level test still does not use the functional Chrome extension path. Asking @chrome list current Chrome tab titles produced a fallback-style answer that only read the foreground Chrome window title and said it could not detect a Chrome DevTools remote debugging port. This is not the expected Codex Chrome extension/native messaging behavior, since the official Chrome extension docs do not require a DevTools remote debugging port.

Direct pipe probe in the same session still succeeds:

Found 5 codex-browser-use pipes.
Chrome extension pipe -> getInfo ok in 39ms, type=extension, name=Chrome
Chrome extension pipe -> getUserTabs ok in 2ms, 6 tabs returned
Current-session IAB pipe -> getInfo ok in 1ms, type=iab, name=Codex In-app Browser
Other IAB pipes returned "Browser session does not belong to this IAB pipe"

So even after elevated sandbox + restart, the extension/native messaging pipe remains healthy, but normal @chrome usage in Codex Desktop does not route through it successfully.

Additional related symptom: Codex Desktop UI cannot remove the Chrome plugin while the Chrome extension host is running from the plugin cache.

Observed in the current Windows session:

Codex UI: Plugins > Chrome > Remove from Codex
Result: toast says plugin uninstall failed (Chinese UI: ??????)

Running process at the same time:
extension-host.exe
ExecutablePath: C:\Users\yunlo\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe
CommandLine: "...\extension-host.exe" chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/ --parent-window=0

This looks related to the same lifecycle/bridge problem rather than a separate Chrome installation issue:

• The Chrome extension/native messaging pipe is alive and can answer direct JSON-RPC (getInfo, getUserTabs).
• Normal @chrome use in Codex Desktop does not reliably route through that backend.
• The plugin uninstall flow also appears unable to stop/release the running extension-host.exe before removing the plugin cache.

Expected behavior:

• When removing the Chrome plugin, Codex should first stop or disconnect the plugin runtime/extension host that is executing from the plugin cache, then remove/disable the plugin cleanly.
• If removal is blocked, the UI should report the exact blocking process/path/error instead of only showing a generic uninstall-failed toast.

This strengthens the hypothesis that this is a Codex Desktop Windows plugin runtime lifecycle issue involving extension-host.exe, named-pipe bridge setup/discovery, and plugin cache cleanup.

Additional narrower diagnostic from the same Windows machine after another Codex update/reinstall attempt.

I found a state where Codex Desktop Settings > Computer Use > Google Chrome showed Connected and extension-host.exe was running, but the official bundled check reported the actual Chrome extension was not installed in the selected Chrome profile:

node scripts/check-extension-installed.js --json
{
  "extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "profilePath": "C:\\Users\\yunlo\\AppData\\Local\\Google\\Chrome\\User Data\\Default",
  "extensionPath": "...\\Default\\Extensions\\hehggadaopoacecdllhhajmbjkdcmajg",
  "installed": false,
  "registered": false,
  "enabled": false,
  "exitCode": 2
}

At the same time the native host manifest was correct:

check-native-host-manifest.js --json -> correct: true
allowedOrigins: ["chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/"]

Process state at that time:

extension-host.exe
CommandLine: "...\\openai-bundled\\chrome\\latest\\extension-host\\windows\\x64\\extension-host.exe" chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/ --parent-window=0

Direct JSON-RPC to the Chrome extension pipe then timed out at getInfo:

\\.\\pipe\\codex-browser-use\\28823fa1-... -> getInfo timeout

After manually stopping the orphaned extension-host.exe processes and opening the official Chrome Web Store URL for the expected extension ID, the official check changed to installed/enabled:

node scripts/check-extension-installed.js --json
{
  "installed": true,
  "registered": true,
  "enabled": true,
  "versions": ["1.1.4_0"],
  "exitCode": 0
}

Direct pipe RPC then recovered:

\\.\\pipe\\codex-browser-use\\c4e2f3dd-... -> getInfo ok
result: { name: "Chrome", version: "1.1.4", type: "extension", extensionId: "hehggadaopoacecdllhhajmbjkdcmajg" }
getUserTabs ok, returned 11 tabs

However, the official setupAtlasRuntime({ globals: globalThis }) path still hung for 60s in node_repl/js. Killing stale node_repl.exe and the child codex.exe app-server --listen stdio:// closed the current node_repl transport, so the next recovery step requires restarting Codex or opening a fresh turn to force recreation of the REPL/tool runtime.

This suggests at least two related lifecycle problems:

1. The UI can show Chrome as Connected while the selected Chrome profile does not have the expected extension installed, because a stale/orphaned extension-host.exe/pipe exists.
2. Even after the real extension is installed and direct pipe RPC succeeds, setupAtlasRuntime() can still hang in the Codex Desktop node_repl native pipe bridge layer.

This also explains why plugin uninstall fails: the plugin cache contains a running extension-host.exe, so removal needs to stop/release that process first and surface the exact blocker if it cannot.

Follow-up: I found and locally verified a workaround that narrows this failure to the browser-use ambient network/account initialization path rather than Chrome itself.

Current environment:

OS: Windows
Codex Desktop package: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
Codex app reported version in process args: 26.506.31421
Bundled codex-cli: 0.130.0-alpha.5
Chrome plugin: openai-bundled/chrome 0.1.7
Codex Chrome Extension: 1.1.4_0
Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg

Key observations:

1. Official extension/native-host checks pass after reinstall:

chrome-is-running.js --json -> ok
check-extension-installed.js --json -> installed=true, registered=true, enabled=true
check-native-host-manifest.js --json -> correct=true

1. The raw Chrome extension pipe is healthy. Direct length-prefixed JSON-RPC to the current \\.\pipe\codex-browser-use\<uuid> pipe returns promptly:

getInfo -> type=extension, name=Chrome, version=1.1.4
getUserTabs -> returns user tabs

1. The official setupAtlasRuntime({ globals: globalThis }) path previously timed out. I then tested the suspected ambient network probe directly inside the built-in Node REPL:

await nodeRepl.fetch(https://chatgpt.com/backend-api/me, { signal: AbortController timeout signal })

That did not return before the tool timeout and reset the kernel. The AbortController did not reliably interrupt the hang.

1. nodeRepl.requestMeta is frozen/non-extensible, so the flag cannot be injected from inside a running JS call:

Cannot add property x-codex-browser-use-disable-ambient-network, object is not extensible

1. I then used a local diagnostic wrapper via CODEX_NODE_REPL_PATH. The wrapper preserves the existing NODE_REPL_REQUEST_META, adds:

{
  x-codex-browser-use-disable-ambient-network: true
}

and execs the official bundled node_repl.exe.

After restarting Codex Desktop, the request metadata included the flag:

{
  x-codex-browser-use-available-backends: [chrome, iab],
  x-codex-browser-use-disable-ambient-network: true
}

With that metadata present, loading from the trusted bundled marketplace path succeeded quickly:

const { setupAtlasRuntime } = await import(file:///C:/Users/<user>/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/chrome/scripts/browser-client.mjs);
const started = Date.now();
await setupAtlasRuntime({ globals: globalThis });
Date.now() - started; // about 100ms

Then the normal browser-use API worked:

const browser = await agent.browsers.get(extension);
const tabs = await browser.user.openTabs();
// returned 10 current Chrome tabs

So for this Windows reproduction, disabling ambient network initialization unblocks the real Chrome extension backend. This is consistent with #21704 and #21722.

Suggested product fix:

• Make the ambient https://chatgpt.com/backend-api/me / account / analytics initialization path non-blocking for Chrome backend discovery.
• Add a strict short timeout and fast-fail behavior around non-essential ambient network probes.
• Expose a supported Codex config setting for x-codex-browser-use-disable-ambient-network or honor BROWSER_USE_DISABLE_AMBIENT_NETWORK=1 in packaged Codex Desktop's built-in Node REPL.
• Surface a clear diagnostic if ambient network initialization is blocking browser setup, instead of letting the user-facing Chrome plugin call time out after 120s.

This workaround does not require reinstalling Chrome and does not change Chrome user data, the Chrome extension, the native messaging manifest, or the plugin cache. It only changes the request metadata passed to the Node REPL runtime before browser-client.mjs initializes.

Windows workaround: manually disable Chrome plugin in Codex config

I was unable to uninstall the Chrome plugin from the Codex UI on Windows.
Even after removing the Codex Chrome extension from Chrome, Codex still showed the Chrome plugin and the UI displayed:

Failed to uninstall plugin

The fix was to manually remove the bundled plugin cache and disable the plugin in the Codex config.

Environment

• OS: Windows
• App: Codex desktop app
• Problem: Chrome plugin cannot be removed/uninstalled from Codex UI

Steps that worked

Close Codex and Chrome first, then run PowerShell as Administrator:

taskkill /F /IM Codex.exe 2>$null
taskkill /F /IM chrome.exe 2>$null
taskkill /F /IM extension-host.exe 2>$null
taskkill /F /IM node.exe 2>$null

Remove-Item "$env:USERPROFILE\.codex\plugins\cache\openai-bundled" -Recurse -Force -ErrorAction SilentlyContinue

Then open the Codex config file:

notepad "$env:USERPROFILE\.codex\config.toml"

Look for Chrome/browser plugin entries such as:

[plugins."chrome@openai-bundled"]
enabled = true

[plugins."browser-use@openai-bundled"]
enabled = true

Change them to:

enabled = false

Save the file and reopen Codex.

Result

After editing config.toml, the Chrome plugin was disabled successfully.
The Codex UI uninstall button still appears unreliable on Windows, but manual config disable works.

Thanks for sharing this workaround. This matches the uninstall/disable part of what I saw locally too: the Codex UI can fail to remove the Chrome plugin on Windows while plugin/runtime processes are still around, and manually disabling the plugin in config.toml plus clearing the plugin cache can get Codex back to a disabled state.

One caution: taskkill /F /IM node.exe can also kill unrelated Node processes outside Codex. If possible, I would narrow the cleanup to Codex-related processes, for example node_repl.exe, extension-host.exe, and codex.exe app-server --listen stdio://, plus Codex.exe itself.

There also seems to be a second, separate failure mode after reinstalling/enabling the extension. In my case the official checks passed:

check-extension-installed.js -> installed=true, registered=true, enabled=true
check-native-host-manifest.js -> correct=true

and direct JSON-RPC to the Chrome extension pipe worked, but the normal setupAtlasRuntime() path still hung. The thing that unblocked runtime usage was disabling the Browser Use ambient network/account initialization path by injecting this request metadata before Node REPL starts:

{
  x-codex-browser-use-disable-ambient-network: true
}

I did that with a local CODEX_NODE_REPL_PATH wrapper that preserves the existing NODE_REPL_REQUEST_META, adds the flag above, and then execs the official bundled node_repl.exe. After restarting Codex Desktop, setupAtlasRuntime() completed in about 100ms and:

const browser = await agent.browsers.get(extension);
const tabs = await browser.user.openTabs();

returned the current Chrome tabs successfully.

So I think there may be two related Windows issues here:

1. Plugin uninstall/cache cleanup does not reliably stop or release extension-host.exe, so UI removal fails.
2. Even after reinstall, Chrome setup can still hang if the ambient https://chatgpt.com/backend-api/me / account initialization path blocks setupAtlasRuntime().

Your workaround is useful for getting back to a disabled/clean plugin state. For users who want the Chrome plugin to remain installed and usable, the ambient-network workaround may be the more relevant direction until Codex makes that initialization non-blocking or exposes a supported config flag.

I've encountered a similar issue.

Windows 10
Codex Desktop
Chrome Extension 1.1.4
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
native host check-native-host-manifest.js: correct true
check-extension-installed.js: installed/registered/enabled true
extension-host.exe running
Chrome popup shows Connected
browser-client.mjs imports successfully
setupAtlasRuntime({ globals }) times out

Additional repro from a Windows Codex Desktop session, specifically for the bundled Browser Use / in-app browser path.

Environment observed locally:

OS: Windows
Codex Desktop app reported version: 26.506.31421
Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha2
Available browser backends in request metadata: ["chrome", "iab"]

Symptom:

const { setupAtlasRuntime } = await import("file:///.../openai-bundled/browser-use/0.1.0-alpha2/scripts/browser-client.mjs");
await setupAtlasRuntime({ globals: globalThis });

The import succeeds, but setupAtlasRuntime({ globals: globalThis }) hangs until the Node REPL tool timeout. Restarting Codex did not clear the issue.

Lower-level diagnostic:

• Multiple \\.\pipe\codex-browser-use-* IAB pipes were present.
• One stale/foreign IAB pipe returned Browser session does not belong to this IAB pipe.
• Another IAB pipe matched the current Codex session and returned:

name: Codex In-app Browser
type: iab
version: 26.506.31421
codexSessionId: matched current session

Direct length-prefixed JSON-RPC to the matching IAB pipe works. These calls succeeded:

getTabs
attach
executeCdp -> Page.navigate
executeCdp -> Runtime.evaluate
executeCdp -> Page.captureScreenshot

Using that direct pipe path I could navigate the Codex in-app browser to https://example.com, read page title/body text, and capture a screenshot. I also served a local HTML deck via http://127.0.0.1:<port>/... and opened it successfully in the in-app browser. file:// navigation was less reliable, but the browser backend itself was clearly controllable.

This suggests the IAB backend is healthy and the failure is in the official Browser Use wrapper initialization/discovery path rather than in the browser runtime itself. A likely fix direction is to make discovery robust when multiple browser-use pipes are present: apply strict per-pipe connect/getInfo/read timeouts, ignore stale or foreign-session pipes, and proceed with the pipe whose codexSessionId matches the current request metadata. The wrapper should also surface which initialization step is blocking instead of hanging until the outer tool timeout.

Thanks for the detailed Windows diagnostics. I maintain a small community Codex Skill focused specifically on Windows Codex Desktop failures around the bundled Chrome and Computer Use plugins:

https://github.com/navi118/codex-desktop-doctor-skill

It is not a general Codex repair script, and it does not make automatic destructive changes. The goal is to help an agent collect the relevant local evidence first, especially around the Codex Chrome Extension/native host, browser/Chrome backend setup, bundled marketplace/cache state, and Windows file-lock / access-denied patterns such as plugin_cache_windows_file_lock, EBUSY, os error 5, missing-helper-path, or Windows Computer Use helper paths are unavailable.

This issue looks related to the same Windows Chrome/browser native-pipe and bundled-cache failure family, especially because local Chrome checks can pass while setupAtlasRuntime() still hangs and the logs show plugin uninstall/cache access-denied failures.

Sharing the Skill here as a cautious evidence-gathering aid, not as an official fix or a recommendation to manually delete cache state.

Additional Windows reproduction confirming this is still present in newer builds (observed July 10, 2026).

Environment

• Windows
• Codex Desktop: 26.707.3748.0
• Codex CLI: 0.144.0
• Chrome: 150.0.7871.101
• ChatGPT Chrome Extension: 1.2.27203.26575_0

Local checks

• Chrome installed and running.
• ChatGPT Chrome Extension installed and enabled in the selected profile.
• Native messaging host manifest and Windows registry entry present and correct.
• Restarting Chrome, Codex Desktop, and Windows did not make the connection reliable.
• Reinstalling the plugin did not resolve the behavior.
• The plugin uninstall flow also failed.

Reproduction

1. Open an authenticated Sleek dashboard in Chrome.
2. Invoke @chrome from Codex Desktop.
3. Chrome connection succeeds: open tabs can be listed, the existing dashboard tab can be claimed, and an initial screenshot/DOM snapshot can be read.
4. Open the page file chooser and attach five synthetic/demo-safe PNG screenshots. The chooser reports success.
5. Request the next DOM snapshot to verify the attachments.
6. The call hangs until the 30-second timeout and resets the browser-control runtime.
7. Chrome remains open under a gray locked overlay. The user cannot interact with the page or normal Chrome controls.
8. Attempts to release the temporary Codex tab group or recover through desktop control are unreliable; the browser can remain stuck even though the page itself is still open.

No credentials, private data, or production/customer data were involved.

This appears to combine the Windows browser/IPC instability described here with the authenticated upload-form hang in #21597. The especially disruptive behavior is that the failure leaves Chrome visibly locked instead of failing fast and releasing user control.