Windows Codex Desktop corrupts chrome@openai-bundled cache on startup when Chrome native host locks extension-host.exe #22114

Summary

On Windows Codex Desktop, the bundled Chrome plugin (chrome@openai-bundled 0.1.7) can become unusable after a Codex App restart if Chrome is already running and the Codex Chrome Extension has started its native messaging host.

The native host runs from inside the plugin cache via the latest junction:

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

On this install, latest points to:

%CODEX_HOME%\plugins\cache\openai-bundled\chrome\0.1.7

During Codex Desktop startup, the app forces a bundled plugin reinstall/refresh. Because extension-host.exe is running from the cache directory being removed/backed up/reinstalled, Windows denies the operation with os error 5. After that, the Chrome plugin cache can be left partially materialized, causing @chrome / Chrome plugin loading to fail.

Environment

• OS: Windows 11 Pro, version 10.0.26200, x64
• Codex Desktop package: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
• Chrome: 147.0.7727.138
• Chrome plugin: chrome@openai-bundled 0.1.7
• Codex Chrome Extension: 1.1.4_0
• Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Codex home path in this report is redacted as %CODEX_HOME%
• Local AppData path in this report is redacted as %LOCALAPPDATA%

User-visible behavior

After installing the Chrome plugin and Chrome extension:

• The Chrome extension shows connected.
• Codex plugin settings indicate the Chrome plugin is installed/enabled, or installation appears to complete.
• In a new Codex thread, tagging @chrome does not expose the Chrome plugin/tools to the assistant.
• Codex logs show missing or invalid plugin.json for chrome@openai-bundled.
• Manually removing/reinstalling the plugin can fail while Chrome is running.

Reproduction

1. On Windows Codex Desktop, install/enable the bundled Chrome plugin.
2. Install/enable the Codex Chrome Extension.
3. Open Chrome so the extension starts the native messaging host.
4. Confirm the native host process is running from:

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

5. Restart Codex Desktop while Chrome/native host remains running.
6. Start a new thread and tag @chrome, or inspect plugin loading logs.

Expected behavior

Codex Desktop should not corrupt or partially remove the installed Chrome plugin cache while the native host is running. It should either:

• avoid reinstalling/removing the active cache path while the native host is running,
• stop/restart the native host safely before replacing the cache,
• install into a new versioned/staged directory and atomically switch latest, or
• fail cleanly without leaving the cache missing .codex-plugin/plugin.json or assets.

Actual behavior

Codex Desktop attempts a forced bundled plugin reinstall/refresh while the native host is still running from the same cache path. Logs show Windows file-lock failures:

bundled_plugin_reinstall_uninstall_requested pluginId=chrome@openai-bundled pluginName=chrome reason=forced
bundled_plugins_marketplace_install_failed errorCategory=plugin_cache_windows_file_lock errorMessage="failed to uninstall plugin: failed to remove existing plugin cache entry: Access is denied. (os error 5)" installedPluginStatus=current installPhase=uninstall_existing installReason=forced marketplaceName=openai-bundled pluginName=chrome

Other attempts showed the same class of failure during install/backup:

bundled_plugins_marketplace_install_failed errorCategory=plugin_cache_windows_file_lock errorMessage="failed to install plugin: failed to back up plugin cache entry: Access is denied. (os error 5)" installPhase=install_plugin marketplaceName=openai-bundled pluginName=chrome

After this, the Chrome plugin cache can be left incomplete. The cache path exists, but .codex-plugin/plugin.json and/or assets may be missing. The app-server then reports:

failed to load plugin: missing or invalid plugin.json plugin="chrome@openai-bundled" path=%CODEX_HOME%\plugins\cache\openai-bundled\chrome\0.1.7

Local evidence

Before restart, the cache was complete:

%CODEX_HOME%\plugins\cache\openai-bundled\chrome\0.1.7
  .codex-plugin
  assets
  extension-host
  scripts
  skills

The source bundled marketplace was also complete and had a valid marketplace entry:

{
  "name": "chrome",
  "source": {
    "source": "local",
    "path": "./plugins/chrome"
  },
  "policy": {
    "installation": "AVAILABLE",
    "authentication": "ON_INSTALL"
  },
  "category": "Productivity"
}

The cache plugin.json hash matched the source plugin.json hash when manually restored, so the source marketplace was not the broken piece.

Windows Restart Manager identified the lock owner as the Chrome plugin native host:

locked file: %CODEX_HOME%\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe
owner: extension-host.exe
command: "%CODEX_HOME%\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe" chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/ --parent-window=0
restartable: false

Isolation experiment

I ran a controlled restart test that temporarily disabled only the Chrome native host registration/manifest, killed the native host process, restored the Chrome plugin cache metadata, then restarted Codex Desktop.

Before Codex restart:

pluginJson=True
assets=True
registry=False
manifest=False
nativeHostProcessCount=0
latestTarget=%CODEX_HOME%\plugins\cache\openai-bundled\chrome\0.1.7

After Codex restart:

pluginJson=True
assets=True
registry=True
manifest=True
nativeHostProcessCount=0
latestTarget=%CODEX_HOME%\plugins\cache\openai-bundled\chrome\0.1.7

The corresponding Codex Desktop startup log showed a clean forced reinstall path instead of the file-lock failure:

bundled_plugins_runtime_marketplace_written pluginCount=3 pluginNames=["browser-use","chrome","latex-tectonic"]
bundled_plugin_reinstall_uninstall_requested pluginId=chrome@openai-bundled pluginName=chrome reason=forced
bundled_plugin_install_requested pluginName=chrome reason=forced
chrome_native_host_install_requested latestRoot=%CODEX_HOME%\plugins\cache\openai-bundled\chrome\latest nativeHostName=com.openai.codexextension pluginName=chrome

This strongly suggests the failure depends on the Chrome native host holding a file lock on the plugin cache during Codex Desktop's forced bundled plugin reinstall/refresh.

Workaround

Close Chrome completely before restarting Codex Desktop or reinstalling the Chrome plugin, making sure both chrome.exe and extension-host.exe are gone. Then restart Codex Desktop, wait for startup/plugin refresh to finish, and reopen Chrome.

This avoids the cache lock and kept .codex-plugin/plugin.json and assets intact in the isolation test.

Related

• Windows Codex Desktop: Chrome plugin and Browser Use setup hang; plugin uninstall fails with os error 5 #21670 — same plugin_cache_windows_file_lock / os error 5 class
• Codex Desktop Chrome plugin times out at setupAtlasRuntime on Windows despite extension/native host checks passing #21878 — same chrome@openai-bundled 0.1.7 native host path and Windows runtime instability
• Windows Desktop: Chrome plugin unavailable in Norway/EU even though extension is connected #21598 — Chrome extension connected but Chrome plugin/backend not exposed