Windows: Chrome native host file lock prevents bundled-marketplaces rebuild, breaking multiple bundled plugins

Open 💬 2 comments Opened Jun 3, 2026 by gevikhn
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows, after installing the Codex Chrome plugin and enabling the corresponding Chrome browser extension, the Chrome extension can keep the Codex Native Messaging host process running from inside the bundled marketplace/cache tree.

The observed executable is:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\extension-host\windows\x64\extension-host.exe

Because Windows locks a running executable, Codex may fail to fully delete or rebuild:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces

This can leave the bundled marketplace partially removed or partially regenerated, causing multiple bundled plugins such as browser, chrome, and computer-use to become unavailable.

This is related to #22114 and #25780, but this report highlights the Native Messaging lifecycle problem: manually killing extension-host.exe is not enough while the Chrome extension remains enabled, because Chrome can start the host again.

Environment

  • OS: Windows
  • Codex App: Windows Store build; package path observed with version 26.527.3686.0
  • Codex Chrome plugin installed
  • Chrome browser extension installed and enabled
  • Chrome extension ID observed in the native host command line: hehggadaopoacecdllhhajmbjkdcmajg

Observed behavior

A native host process remains running from the Codex bundled marketplace/cache path:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\extension-host\windows\x64\extension-host.exe

or from the plugin cache path:

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

The process command line includes the Chrome extension origin:

chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/

This indicates that it is being launched by Chrome through Native Messaging. If the process is killed manually while the Chrome extension remains enabled, Chrome can automatically start it again.

Impact

When Codex updates, starts, or rebuilds bundled marketplace contents, it attempts to remove or recreate the bundled marketplace directory. If extension-host.exe is still running from inside that tree, Windows prevents complete deletion or replacement.

After this happens, the marketplace can be left incomplete, which prevents multiple bundled plugins from being discovered or loaded. The visible symptom is not only that the Chrome plugin fails, but that several OpenAI-bundled plugins become unavailable, including at least:

browser
chrome
computer-use

Expected behavior

Codex should avoid corrupting the bundled marketplace when the Chrome Native Messaging host is running.

Possible expected behaviors:

  1. Do not run long-lived native host binaries from a temporary or mutable marketplace/cache directory that may be deleted during updates.
  2. Before deleting or rebuilding the bundled marketplace, stop or unregister the Chrome Native Messaging host, or prompt the user to fully close Chrome / disable the Codex Chrome extension.
  3. Use a robust staging plus atomic swap strategy, preserving the previous complete marketplace if deletion or replacement fails.
  4. If a file lock is detected, report a clear actionable error instead of leaving bundled-marketplaces in a partially generated state.
  5. Ensure one locked plugin host cannot corrupt the entire openai-bundled marketplace and break unrelated bundled plugins.

Workaround

A manual workaround is:

  1. Disable the Codex Chrome extension in Chrome.
  2. Fully close Chrome, including background apps.
  3. Close Codex.
  4. Kill any remaining extension-host.exe process.
  5. Delete %USERPROFILE%\.codex\.tmp\bundled-marketplaces.
  6. Restart Codex and let it regenerate the bundled marketplace.
  7. Re-enable or reinstall the Chrome plugin afterward.

This workaround suggests the failure is strongly related to the Native Messaging host keeping files locked while Codex rebuilds the bundled marketplace.

Related issues:

  • #22114
  • #25780
  • #21670
  • #24296

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25780
  • #25878

Powered by Codex Action

zemeng5208 · 16 days ago

Disclosure: I maintain WinBridge Recovery, a Windows-only Codex Desktop recovery/diagnostic project.

This issue has a useful distinction: the native-host lock is the trigger, but the lasting user-visible failure is the partially regenerated openai-bundled marketplace and plugin cache left behind afterward. That persistent state is where WinBridge Recovery is intended to help.

It checks the currently installed official package against the generated bundled marketplace and versioned plugin state, preserves a backup, and can repair stale/incomplete user-side marketplace/cache/latest/native-host registration state. It does not modify WindowsApps or try to bypass Windows file locking.

So I would not present it as a fix for the native-host lifecycle bug itself. If Chrome keeps relaunching the locked host, the upstream problem remains. But after the host is stopped, it may provide a safer, repeatable recovery path for the broken marketplace/plugin state described here.