codex - 💡(How to fix) Fix 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:

1. 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.
2. 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

1. Install Codex Desktop on Windows.
2. Install and enable the Codex Chrome Extension.
3. 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.
4. Open Chrome and use the Codex Chrome Extension so the native host is running.
5. Start/restart Codex Desktop and allow bundled plugins to reconcile.
6. Observe repeated plugin_cache_windows_file_lock / os error 5 plugin cache warnings.

Minimal reproduction for Issue 2

1. Ensure Chrome, Codex Chrome Extension, and Native Messaging host are installed correctly.
2. 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.
3. 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.