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

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

• #23831
• #22849
• #23322
• #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:

1. Chrome or its native host can keep a file handle open inside the mutable bundled plugin cache.
2. Codex update/startup reconciliation then fails to back up/remove/replace that cache entry.
3. The bundled marketplace/cache state can become partially updated.
4. 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:

1. Do not run long-lived native hosts from mutable plugin cache paths that Codex later backs up, removes, or replaces.
2. 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.
3. 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.
4. Make bundled plugin reconciliation atomic: do not switch config/marketplace/plugin state until the new mirror/cache has been fully written and validated.
5. If reconcile fails, roll back cleanly instead of leaving other bundled plugins with missing helper paths.
6. 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.
7. 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:

1. The native-host checker has a Windows localization/encoding bug when parsing the default registry value name.
2. 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:

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

1. The locking process is the Chrome plugin's own extension-host.exe, launched through the openai-bundled/chrome/latest/... path.
2. Stopping that exact process does not provide a usable removal window: Codex immediately respawns it under a new PID, and deletion fails again.
3. Moving the entire openai-bundled/chrome directory out of the active cache path also fails with access denied while Codex is running.
4. 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

1. The supported plugin uninstall failed with:

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

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

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

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

``text
bundled_plugin_chrome_extension_sync_decision
chromeExtensionSyncAction=keep_installed
isExtensionInstalled=true
isPluginSyncManaged=true
``

followed by bundled_plugin_install_requested and plugin_install_succeeded.

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

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

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

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