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

Summary

On Windows Codex Desktop, the Chrome plugin and shared browser automation bridge are unstable. The Chrome plugin can sometimes open a basic HTTPS page and read the title, but it is very slow and unreliable; direct browser-client setup calls hang until timeout. The Codex plugin UI also cannot uninstall the bundled Chrome plugin.

Environment

OS: Windows
Codex Desktop package: OpenAI.Codex_26.506.2212.0_x64
Plugin: chrome@openai-bundled 0.1.7
Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Chrome extension version: 1.1.4_0
Chrome plugin config: [plugins."chrome@openai-bundled"] enabled = true
Current browser backends exposed in the turn metadata: ["chrome", "iab"]

Reproduction

Restart Codex Desktop.
Enable the bundled Chrome plugin in Codex plugins settings.

Ask Codex:

@chrome open https://example.com and read the page title

Observe that it can sometimes succeed, but one run took about 1m50s for a trivial page title read.

Ask Codex to inspect Chrome bookmarks:

@chrome can you view my bookmarks directory?

It reports that the Chrome plugin/tool is unavailable for that task.
In Codex plugin settings, attempt to uninstall the Chrome plugin.
The UI shows a toast in Chinese: 插件卸载失败 (Plugin uninstall failed).

Direct diagnostics

From the agent-side Node REPL / browser-client path:

Importing the Chrome plugin browser-client.mjs succeeds quickly (~47ms).
Calling setupAtlasRuntime({ globals }) for the Chrome plugin hangs until tool timeout (120s).
Calling setupAtlasRuntime({ globals, backend: "iab" }) for the in-app browser backend also hangs until timeout (120s), so the issue may be in the shared browser-use/native pipe bridge, not only the Chrome extension.

The current turn metadata includes:

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

Local health checks that pass

The plugin-provided diagnostic scripts report that the local pieces are present:

Chrome is installed and running.
The Codex Chrome Extension is installed and enabled.
The native host manifest exists and points to the bundled Chrome plugin latest extension host.
The expected extension origin is allowed.

Relevant log lines

The Codex Desktop logs contain repeated plugin uninstall failures:

failed to uninstall plugin: failed to remove existing plugin cache entry: 拒绝访问。 (os error 5)

They also contain browser/IPC instability:

IpcRouter Socket error: write EPIPE
app_server_connection.state_changed ... next=disconnected

There are also bundled plugin cache install/update warnings on Windows:

bundled_plugins_marketplace_install_failed
errorCategory=plugin_cache_windows_file_lock
errorMessage="failed to install plugin: failed to back up plugin cache entry: 拒绝访问。 (os error 5)"

Expected behavior

@chrome setup should initialize reliably or fail fast with a clear error.
Browser automation setup should not hang until the outer 120s tool timeout.
The Chrome plugin should reliably handle simple page tasks such as opening https://example.com and reading the title.
The plugin UI should either uninstall the plugin or clearly explain that bundled plugins cannot be uninstalled.
If Chrome bookmarks / chrome:// internal pages are intentionally unsupported, the model/plugin should report that limitation directly rather than implying the Chrome plugin/tool is unavailable.

Actual behavior

Simple page-title reading can work, but is very slow and unreliable.
Direct setup calls for both Chrome and IAB browser backends hang until timeout.
The Chrome plugin UI uninstall flow fails with a generic toast.
Logs point to Windows file-lock/access-denied failures and IPC disconnection.

Related issues checked

This appears related to other Windows browser/app-server issues, but this report includes the Chrome plugin and plugin uninstall failure combination:

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

Windows Codex App: Browser Use fails to discover IAB backend despite node_repl and in-app browser working #21530
Chrome plugin file upload setFiles fails with Not allowed and upload forms can hang #21597
Windows Desktop: Chrome plugin unavailable in Norway/EU even though extension is connected #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:

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.
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:

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

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

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.

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

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.

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:

Plugin uninstall/cache cleanup does not reliably stop or release extension-host.exe, so UI removal fails.
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

Open an authenticated Sleek dashboard in Chrome.
Invoke @chrome from Codex Desktop.
Chrome connection succeeds: open tabs can be listed, the existing dashboard tab can be claimed, and an initial screenshot/DOM snapshot can be read.
Open the page file chooser and attach five synthetic/demo-safe PNG screenshots. The chooser reports success.
Request the next DOM snapshot to verify the attachments.
The call hangs until the 30-second timeout and resets the browser-control runtime.
Chrome remains open under a gray locked overlay. The user cannot interact with the page or normal Chrome controls.
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.

Disclosure: I’m the maintainer of WinBridge Recovery.

The plugin_cache_windows_file_lock / os error 5 part of this report is closely related to the Windows Chrome-cache failure modes the project handles after the lock event: incomplete versioned cache, stale latest, and native-host/plugin registration that no longer matches the currently installed Codex build.

The utility can back up and validate that user-side state, then repair the cache/pointer/registration drift once the locked native host is no longer active. It deliberately does not try to force-delete a running extension-host.exe or modify protected WindowsApps contents.

That means it is not a fix for the shared browser-runtime hang or IPC EPIPE by itself. If those remain after the Chrome cache and native-host state validate cleanly, they are separate upstream runtime issues. But it can help recover the local plugin state that repeated file-lock failures may leave behind and avoid manual reconstruction of each cache/registration component.

Current-build Windows data point from Codex Desktop 26.915.4065.0:

On the first launch after the Store update, bundled-plugin reconciliation logged one plugin_cache_windows_file_lock / Access is denied (os error 5) while trying to back up the bundled browser plugin cache.
The installed browser cache already contained the current bundled generation 26.915.31945.
After a controlled Desktop-only full quit/reopen, the same reconciliation path produced 0 plugin_cache_windows_file_lock and 0 Access is denied records.
No manual cache deletion, junction edit, registry edit, or WindowsApps modification was performed.
The second launch also settled to a bounded Desktop-owned app-server tree.

This suggests the cache-lock class still exists on the current build, but in this run it was transient and recovered after a clean Desktop restart rather than leaving persistent cache damage. I did not run a browser automation task, so this does not establish whether the separate runtime/setup hang described in this issue is resolved.

Navigation Menu

Repository navigation

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

Summary

Environment

Reproduction

Direct diagnostics

Local health checks that pass

Relevant log lines

Expected behavior

Actual behavior

Related issues checked

Windows workaround: manually disable Chrome plugin in Codex config

Environment

Steps that worked

Environment

Local checks

Reproduction

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Reproduction

Direct diagnostics

Local health checks that pass

Relevant log lines

Expected behavior

Actual behavior

Related issues checked

Activity

github-actions commented on May 8, 2026

Boboo-Zhao commented on May 8, 2026

m13v commented on May 8, 2026

Electro-Dig commented on May 9, 2026

Electro-Dig commented on May 9, 2026

Electro-Dig commented on May 9, 2026

Electro-Dig commented on May 9, 2026

Electro-Dig commented on May 9, 2026

shokrat301 commented on May 10, 2026

Windows workaround: manually disable Chrome plugin in Codex config

Environment

Steps that worked

Electro-Dig commented on May 10, 2026

bingohu commented on May 10, 2026

Innerpeace1990 commented on May 12, 2026

navi118 commented on Jun 3, 2026

bfeller05 commented on Jul 10, 2026

Environment

Local checks

Reproduction

zemeng5208 commented on Aug 12, 2026

PracticalSwan commented on Sep 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions