Codex Desktop on Windows: Chrome native host locks plugin cache and Chrome routing is unreliable

Summary

I am seeing two related reliability problems with the Codex Desktop Chrome/browser plugin flow on Windows:

The Chrome Native Messaging host appears to run from the mutable Codex bundled plugin cache. When Chrome launches the native host, Windows locks the running .exe, and Codex later fails bundled plugin reconciliation with plugin_cache_windows_file_lock / os error 5.
Even when the Chrome extension is installed and usable, models sometimes fail to route to the Chrome plugin after the user explicitly requests Chrome/plugin usage. The model may look for a direct chrome tool, fall back to screenshots or another browser backend, and only use Chrome correctly after repeated prompting or restart.

Environment

Product: Codex Desktop App on Windows
Codex Desktop package observed: OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0
App/plugin log version annotation observed: 26.519.41501
Chrome extension installed and enabled
Chrome running during the issue
User-level Chrome Native Messaging host registry entry existed for the Codex extension

Issue 1: Native host file lock during plugin cache reconciliation

The Chrome Native Messaging manifest appears to point the native host executable into the Codex bundled plugin cache, specifically under the openai-bundled/chrome/latest/extension-host/windows/x64/extension-host.exe cache tree.

On Windows, a running executable is locked. When Chrome launches this native host via Native Messaging, the executable remains in use. Codex then attempts to install, remove, back up, or reconcile the bundled Chrome/browser plugin cache and fails because the executable or its parent cache tree is locked.

Representative log excerpts:

bundled_plugins_marketplace_install_failed
bundledPluginSourcePath=./plugins/chrome
errorCategory=plugin_cache_windows_file_lock
errorMessage="failed to install plugin: failed to back up plugin cache entry: Access is denied. (os error 5)"

bundled_plugins_reconcile_failed
errorMessage="failed to install plugin: failed to back up plugin cache entry: Access is denied. (os error 5)"

A related browser plugin cache failure was also observed:

bundledPluginSourcePath=./plugins/browser
errorCategory=plugin_cache_windows_file_lock
errorMessage="failed to uninstall plugin: failed to remove existing plugin cache entry: Access is denied. (os error 5)"

This repeated across multiple app sessions. Directory permission checks indicated the user account had full control over the relevant cache directory, so this looks more like a Windows executable file lock than a normal ACL permission problem.

Killing stale helpers temporarily stopped new file-lock errors, but the problem later recurred when Chrome relaunched the native host. That suggests the root issue is not only stale processes; it is that the registered Native Messaging host path points into a mutable cache entry.

User-visible impact of Issue 1

Chrome plugin features feel unreliable.
Codex repeatedly logs plugin reconcile/install failures.
Chrome native messaging helper processes can remain running after Codex is closed.
Restarting Codex does not necessarily clear the issue because Chrome can relaunch the native host.
Codex can leave behind orphaned helper processes.
Codex sessions/windows may feel unstable or restart-like, although no native crash report was confirmed in this inspection.

Expected behavior for Issue 1

Codex should be able to reconcile bundled plugins without failing because Chrome is using the Native Messaging host.

The Chrome Native Messaging host should not be registered to a path inside a mutable plugin cache that the app later backs up, removes, or replaces.

Suggested fixes for Issue 1

Install the Chrome Native Messaging host executable into a stable, non-cache location.
Register the Native Messaging manifest to that stable path, not to openai-bundled/chrome/latest/... inside the mutable plugin cache.
Avoid using a mutable latest reparse/symlink-style target as the executable path for Chrome Native Messaging.
If the native host must be versioned, install new versions side by side, atomically update the manifest, and defer deletion of old locked executables until they are no longer running.
Detect active native host processes before plugin cache reconciliation and provide a user-facing recovery path.

Issue 2: Chrome plugin routing is unreliable from the model side

The user experience is that explicit Chrome plugin requests are not always honored by the model/tooling path.

Even when setup appears correct:

Chrome is installed and running.
The Codex Chrome Extension is installed and enabled.
The Native Messaging host exists.
The extension can be reached later in the same session.

The assistant may still fail to use Chrome at first. In one affected session, the user explicitly invoked the Chrome plugin link, but the assistant reported that it did not have a direct Chrome tool and used a desktop screenshot fallback instead. Later in the same session, after retry/restart, the assistant successfully connected to Chrome through the browser-client / Node REPL flow and opened authenticated Chrome pages. This suggests a model-facing routing or entry-point reliability issue, not simply a missing user installation.

Evidence from local skill/tooling shape

The local Chrome skill trigger appears narrow, centered on @chrome. Users may naturally say things like:

use Chrome
use the Chrome plugin
use my logged-in Chrome
use the Codex Chrome Extension
current Chrome tab

These are explicit Chrome requests, but may not reliably route the model into the Chrome skill.

The operational entry point is also fairly indirect. The model does not appear to get a simple first-class chrome.openTabs / chrome.status / chrome.newTab style tool. Instead, the model has to discover or remember a flow similar to:

load/read the Chrome skill
use the Node REPL JavaScript tool
import the plugin browser-client module
run setupBrowserRuntime(...)
select the extension browser backend
claim or create a tab
clean up/finalize tabs afterward

That is a fragile model-facing path and gives a plausible mechanism for the observed behavior where explicit Chrome requests are missed or routed to the wrong backend.

User-visible impact of Issue 2

User explicitly asks for Chrome plugin use, but the assistant may not use it.
Assistant may claim it cannot find the Chrome entry point.
Assistant may use a screenshot fallback, in-app browser, or another browser backend.
User must repeatedly remind the model to use Chrome.
The feature feels unstable even when installation is correct.

Expected behavior for Issue 2

When the user explicitly mentions Chrome, Chrome plugin, Codex Chrome Extension, logged-in Chrome, existing Chrome tabs, or authenticated Chrome state, the model should reliably route to the Chrome plugin.

A robust model-facing path would be:

If user requests Chrome/Codex Chrome Extension/authenticated Chrome/current Chrome tab:
1. Load Chrome skill.
2. Run a lightweight connection check.
3. If connection works, use the extension backend.
4. If connection fails, run documented checks and report the exact failing component.

Suggested fixes for Issue 2

Broaden the Chrome skill trigger beyond only @chrome to include natural-language requests for Chrome, the Chrome plugin, the Codex Chrome Extension, current Chrome tabs, logged-in Chrome, existing Chrome tabs, Chrome profile/session/cookies, etc.
Expose a first-class Chrome tool or clearer tool alias, even if it wraps the existing browser-client / Node REPL flow internally.
Put a short "do this first" section at the top of the Chrome skill.
Separate routing/setup/API/troubleshooting documentation so the critical entry path is hard to miss.
Improve diagnostics when the extension is installed but communication is unstable, especially when the native host is running from a mutable plugin cache.

Minimal reproduction for Issue 1

Install Codex Desktop on Windows.
Install and enable the Codex Chrome Extension.
Confirm the Chrome Native Messaging host points to the bundled Chrome plugin cache under openai-bundled/chrome/latest/extension-host/windows/x64/extension-host.exe.
Open Chrome and use the Codex Chrome Extension so the native host is running.
Start/restart Codex Desktop and allow bundled plugins to reconcile.
Observe repeated plugin_cache_windows_file_lock / os error 5 plugin cache warnings.

Minimal reproduction for Issue 2

Ensure Chrome, Codex Chrome Extension, and Native Messaging host are installed correctly.
In Codex, ask the assistant in natural language to use the Chrome plugin, for example: Use the Chrome plugin to inspect my current Chrome tab.
Observe that the assistant may fail to route to Chrome, may look for a wrong entry point, may use another browser backend, or may require repeated reminders before using Chrome correctly.

Requested outcome

Please fix the Chrome plugin architecture so the native host is not run from a mutable plugin cache path, and improve the model-facing Chrome skill/tool entry point so explicit Chrome plugin requests are reliably honored.

I can provide more detailed local evidence privately if maintainers need it, but I am avoiding public raw session excerpts and local workspace details in this issue.

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

Chrome plugin disappeared from Codex App marketplace after update; cached browser-client is not trusted #23831
Windows: Chrome plugin can open Chrome/page but fails to establish usable browser-control session #22849
Codex Desktop Chrome plugin unavailable even though extension and native host are installed #23322
@chrome mention does not load or surface Chrome skill #22888

Powered by Codex Action

Thanks for the duplicate detection. I reviewed the linked issues (#23831, #22849, #23322, and #22888).

This issue appears related, but not a full duplicate. It includes a specific Windows file-lock failure mode where the Chrome Native Messaging host is registered to and launched from the mutable Codex plugin cache path, under openai-bundled/chrome/latest/extension-host/windows/x64/extension-host.exe. When Chrome launches that native host, Windows locks the running executable, and Codex later fails bundled plugin reconciliation with plugin_cache_windows_file_lock / os error 5.

It also combines that native-host/cache lifecycle issue with a separate model/tool-routing problem: explicit Chrome plugin requests can fail to route into the Chrome skill/tool path even when the Chrome extension and native host are installed and later prove usable.

So I believe the linked issues are useful related context, but this issue should stay open unless maintainers decide it is covered by a more specific tracking issue.

Additional update: Windows update/reconcile failure can leave bundled plugins partially broken

I hit this again on a newer Codex Desktop build, and this time the failure had a broader user-visible impact than just Chrome routing.

Environment observed

Product: Codex Desktop on Windows
Codex Desktop package observed: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
Bundled plugin/runtime release annotation observed in logs: 26.601.21317
Chrome extension/native host was in use around the time of the issue
Affected bundled plugins: Chrome and Computer Use

What happened

After updating/restarting Codex Desktop, the bundled plugin reconcile flow failed on the Chrome plugin cache with a Windows file-lock / access-denied error. After that partial failure, the app state was inconsistent enough that Computer Use also failed to start because its helper path was unavailable.

Representative sanitized log excerpts:

warning [BundledPluginsMarketplace] bundled_plugins_marketplace_install_failed
bundledPluginSourcePath=./plugins/chrome
errorCategory=plugin_cache_windows_file_lock
errorMessage="failed to install plugin: failed to back up plugin cache entry: 拒绝访问。 (os error 5)"
installedPluginCacheRoot=%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome
marketplaceRoot=%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled
pluginName=chrome

warning [bundled-plugins] bundled_plugins_reconcile_failed
errorMessage="failed to install plugin: failed to back up plugin cache entry: 拒绝访问。 (os error 5)"
reason=startup

Immediately after the plugin reconcile failure, Computer Use could not resolve its helper path:

info [computer-use-native-pipe] computer-use notify config ensure finished
reason=missing-helper-path
status=skipped

warning [computer-use-native-pipe] computer-use native pipe startup failed
errorMessage="Windows Computer Use helper paths are unavailable"

After manually rebuilding the bundled plugin mirror/cache back to the same default locations that Codex normally uses, both plugins recovered:

info [computer-use-native-pipe] computer-use native pipe startup ready
pipePath=\\.\pipe\codex-computer-use-...

info [electron-message-handler] browser_use_availability_resolved
available=true
platform=Windows
release=26.601.21317

Functional verification after recovery:

Computer Use could list installed Windows apps, open QQ Music, and control playback.
Chrome plugin could connect to the Codex Chrome Extension, open https://example.com/, read the page title/body, and capture a screenshot.

Why this matters

This looks like the same underlying Chrome native-host/cache lifecycle issue described above, but the consequence is larger than Chrome alone:

Chrome or its native host can keep a file handle open inside the mutable bundled plugin cache.
Codex update/startup reconciliation then fails to back up/remove/replace that cache entry.
The bundled marketplace/cache state can become partially updated.
Other bundled plugins, such as Computer Use, may then fail because expected helper paths are missing or not wired correctly.

So the current failure mode is not merely: "Chrome plugin is unreliable." It can become: "Codex bundled plugin reconciliation leaves the whole bundled plugin set in an inconsistent state after an update."

Reasonable fixes

I think the fix should be in the update/reconcile lifecycle, not in user workarounds:

Do not run long-lived native hosts from mutable plugin cache paths that Codex later backs up, removes, or replaces.
Move the Chrome native messaging host executable to a stable non-cache location, or use side-by-side immutable version directories and defer deletion of locked old versions.
Add a preflight check before bundled plugin reconciliation on Windows: detect running helpers such as extension-host.exe from the target cache tree and either wait, ask the user to close Chrome, or skip destructive cache replacement until safe.
Make bundled plugin reconciliation atomic: do not switch config/marketplace/plugin state until the new mirror/cache has been fully written and validated.
If reconcile fails, roll back cleanly instead of leaving other bundled plugins with missing helper paths.
Add an automatic recovery path that rebuilds %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled and %USERPROFILE%\.codex\plugins\cache\openai-bundled from the installed official bundled source when the app detects missing helper paths or partial cache state.
Show a clear user-facing message if Chrome is blocking a plugin update, instead of silently leaving Chrome/Computer Use unavailable.

The important point: manually rebuilding the official bundled mirror/cache restored functionality without any custom runtime path, so the expected default structure is fine. The bug is that the official update/reconcile process can fail under Windows file locks and leave that default structure incomplete.

I can reproduce a related but slightly different failure mode on Windows with Codex Desktop 26.609.x.

In my case the Native Messaging registration is no longer missing: the HKCU registry key exists, the manifest exists, and Chrome has launched extension-host.exe, but the Codex browser runtime still does not expose the Chrome extension backend.

Environment observed:

OS: Windows
Codex Desktop package path includes: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
Chrome bundled plugin version path: openai-bundled/chrome/26.609.41114
Codex Chrome Extension version: 1.1.5
Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Native host name: com.openai.codexextension

Native Messaging state:

Registry key exists:
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
Registry default value points to:
%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
Manifest exists and contains:
- name: com.openai.codexextension
- allowed_origins: chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/
- path: %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe
latest is a junction to the current plugin version.
extension-host.exe exists and is running.
The running host command line is approximately:
extension-host.exe chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/ --parent-window=0

However, after initializing the bundled Chrome browser-client runtime:

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

The only discovered backend is the Codex in-app browser:

type: iab
name: Codex In-app Browser

These all fail:

agent.browsers.get("extension") -> Browser is not available: extension
agent.browsers.get("chrome")    -> Browser is not available: chrome
agent.browsers.get("cdp")       -> Browser is not available: cdp

Opening the selected Chrome profile with the bundled recovery helper also does not fix it:

scripts/open-chrome-window.js
status: opened
profile: Default

After waiting and retrying, agent.browsers.list() still only returns iab.

One extra diagnostic issue: on this Chinese Windows environment, scripts/check-native-host-manifest.js --json can falsely report that the registry key is missing. The reason appears to be that Node's execFile("reg", ["query", key, "/ve"], { encoding: "utf8" }) receives a localized/default-value label as mojibake:

(Ĭ��)    REG_SZ    %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

The checker only parses (Default), so it returns registryManifestPath: null even though PowerShell and raw reg query show that the key exists.

So there seem to be two separate problems:

The native-host checker has a Windows localization/encoding bug when parsing the default registry value name.
Even when Native Messaging is actually registered and extension-host.exe is running, the Codex browser runtime may still fail to discover/expose the Chrome extension backend and only exposes iab.

Expected behavior:

If the registry key, manifest, extension, and running native host are present, agent.browsers.list() should include the Chrome extension backend.
agent.browsers.get("extension") or the documented Chrome plugin path should work.
The native-host checker should parse the default registry value robustly on localized Windows systems, or use a registry API / value-type parse that does not depend on the localized display name.

Still reproducible on a substantially newer Windows Codex Desktop build.

Environment:

Codex Desktop package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
Bundled Chrome plugin cache version: 26.707.72221
Plugin: chrome@openai-bundled
Windows

Observed removal sequence:

The supported plugin-management uninstall action fails immediately with only Failed to uninstall plugin. This happens with both the canonical identifier chrome@openai-bundled and the user-facing name Chrome, including after restarting Codex.
Direct removal of the verified plugin cache fails on:
openai-bundled/chrome/26.707.72221/extension-host/windows/x64/extension-host.exe
with Windows access denied.
The locking process is the Chrome plugin's own extension-host.exe, launched through the openai-bundled/chrome/latest/... path.
Stopping that exact process does not provide a usable removal window: Codex immediately respawns it under a new PID, and deletion fails again.
Moving the entire openai-bundled/chrome directory out of the active cache path also fails with access denied while Codex is running.
Two stale plugin-backup-* directories containing Chrome plugin backups were present from earlier failed operations.

This confirms the native-host/mutable-cache lock and adds a removal-specific problem: the app respawns the process that blocks its own uninstaller, while returning no actionable error to the user. A robust uninstall likely needs to disable native-host respawn first, terminate the matching host, remove or defer-delete the cache, and then clean stale backup directories.

Additional reproduction: uninstall failure and startup auto-reinstall are coupled by Chrome-extension sync

I can still reproduce this on Windows in the Codex Desktop 26.721 line:

Windows NT 10.0.26200.0
Codex Desktop: initial reproduction on 26.721.4979.0; current package after restart/update is 26.721.11231.0
Bundled plugin observed: chrome@openai-bundled 26.721.41059
Chrome 150.0.7871.187
Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg

Observed sequence

The supported plugin uninstall failed with:

failed to uninstall plugin: failed to remove existing plugin cache entry: Access is denied. (os error 5)
errorCategory=plugin_cache_windows_file_lock

The extension host was running directly from the mutable plugin cache:

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

Stopping the host and removing/moving the cache only removed the plugin temporarily. Restarting Codex recreated the cache. The app logs showed the reconciliation decision:
```
bundled_plugin_chrome_extension_sync_decision
chromeExtensionSyncAction=keep_installed
isExtensionInstalled=true
isPluginSyncManaged=true
```
followed by bundled_plugin_install_requested and plugin_install_succeeded.
The Chrome extension was present in two Chrome profiles. Removing it from only one profile was insufficient: Codex still detected an installed extension and reinstalled/kept the bundled plugin.

After removing the extension from both Chrome profiles, Codex logged:

bundled_plugin_chrome_extension_sync_decision
chromeExtensionSyncAction=uninstall_managed
isExtensionInstalled=false
isPluginSyncManaged=true
bundled_plugin_uninstall_requested reason=chrome_extension_uninstalled
plugin_uninstall_succeeded

Final verification then showed the plugin manager returning not_installed, with the plugin cache, native-host registration/manifest, and sync-management marker all absent.

Interpretation

There appear to be two coupled behaviors:

The Windows native host runs from the mutable plugin cache and can lock the files its own uninstaller needs to remove.
The bundled-plugin reconciler treats the Chrome extension in any profile as the source of truth. A plugin-only removal is reversed on startup while that extension remains installed.

This explains why the UI uninstall fails and why a manual cache cleanup can appear to “undo itself” after restarting Codex.

Expected behavior / suggestions

Stop the native host and prevent respawn before deleting the plugin cache.
Make the UI explain that this plugin is sync-managed by the Chrome extension.
Offer a linked removal flow that removes/disables both the Codex plugin and the corresponding Chrome extension (or provides an explicit way to disable synchronization).
Avoid running a long-lived host from a mutable cache directory, or use versioned/atomic replacement.
Surface an actionable Windows file-lock message rather than a generic uninstall failure.

Disclosure: I maintain WinBridge Recovery, an independent Windows recovery utility for Codex Desktop.

This issue is directly relevant to the project because the native-host lock and the broken state left after reconciliation need to be treated as two separate problems. A running extension-host.exe (and sometimes Codex-owned Node workers) can block cache replacement; after that failure, latest, the versioned cache, marketplace metadata and native-host registration can disagree even after the lock is gone.

WinBridge Recovery focuses on that recoverable local-state layer: resolve the currently installed official Codex package, validate the versioned plugin cache and active pointers/registration, create a rollback backup, and rebuild only the inconsistent user-side pieces. It deliberately does not take ownership of WindowsApps or try to defeat an active Windows file lock.

For an active lock, the safer sequence is to identify/quiesce the plugin-owned host/workers first, then repair and verify the cache/pointers/registration. The model/tool-routing portion of this issue is also outside what a local recovery utility can guarantee; if the local Chrome bridge is healthy but the session still does not receive the tool, that remains an upstream runtime/routing problem.

This problem is still occurring on Windows.

The official Codex Chrome extension is installed, enabled, and shows “Connected,” but Codex still cannot discover, read, or control Chrome tabs.

Troubleshooting already completed:

Updated the extension
Fully closed and restarted Chrome
Removed and reinstalled the official extension
Reopened a normal signed-in ChatGPT tab

The failure still occurs. The current runtime error is:

Trusted RPC dependency must resolve within a configured trusted code path

The error points to the bundled browser-service.mjs component. For privacy, I am not posting the full local file path.

Related diagnostic feedback ID:
01a00a63-9522-74a2-a718-9b2f7d64e0b2

Please link that diagnostic upload to this issue and advise whether a fix or additional supported diagnostic step is available.

Navigation Menu

Repository navigation

Codex Desktop on Windows: Chrome native host locks plugin cache and Chrome routing is unreliable #24296

Summary

Environment

Issue 1: Native host file lock during plugin cache reconciliation

User-visible impact of Issue 1

Expected behavior for Issue 1

Suggested fixes for Issue 1

Issue 2: Chrome plugin routing is unreliable from the model side

Evidence from local skill/tooling shape

User-visible impact of Issue 2

Expected behavior for Issue 2

Suggested fixes for Issue 2

Minimal reproduction for Issue 1

Minimal reproduction for Issue 2

Requested outcome

Additional update: Windows update/reconcile failure can leave bundled plugins partially broken

Environment observed

What happened

Why this matters

Reasonable fixes

Additional reproduction: uninstall failure and startup auto-reinstall are coupled by Chrome-extension sync

Observed sequence

Interpretation

Expected behavior / suggestions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Codex Desktop on Windows: Chrome native host locks plugin cache and Chrome routing is unreliable #24296

Description

Summary

Environment

Issue 1: Native host file lock during plugin cache reconciliation

User-visible impact of Issue 1

Expected behavior for Issue 1

Suggested fixes for Issue 1

Issue 2: Chrome plugin routing is unreliable from the model side

Evidence from local skill/tooling shape

User-visible impact of Issue 2

Expected behavior for Issue 2

Suggested fixes for Issue 2

Minimal reproduction for Issue 1

Minimal reproduction for Issue 2

Requested outcome

Activity

github-actions commented on May 24, 2026

navi118 commented on May 24, 2026

navi118 commented on Jun 3, 2026

Additional update: Windows update/reconcile failure can leave bundled plugins partially broken

Environment observed

What happened

Why this matters

Reasonable fixes

yc99-gif commented on Jun 15, 2026

harryminh1301 commented on Jul 20, 2026

Electro-Dig commented on Jul 30, 2026

Additional reproduction: uninstall failure and startup auto-reinstall are coupled by Chrome-extension sync

Observed sequence

Interpretation

Expected behavior / suggestions

zemeng5208 commented on Aug 12, 2026

nmexcusesapps-create commented on Aug 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions