Windows: startup bundled-plugins reconcile races Chrome extension-host.exe (EBUSY) — Computer Use + Chrome plugins disappear; CU helper "paths unavailable"

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

• #27152
• #25795
• #25780

Powered by Codex Action

Additional confirmation from another Windows Codex Desktop install. This still reproduces on:

• Codex Desktop: OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0
• OS: Windows
• Bundled Chrome plugin enabled, Codex Chrome extension/native host active

Observed on startup:

2026-06-16T04:17:07.864Z info [browser-use-native-pipe-server] browser-use native pipe listening pipePath=\\.\pipe\codex-browser-use-...
2026-06-16T04:17:12.635Z info [computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-... platform=win32
2026-06-16T04:17:15.886Z warning [BundledPluginsMarketplace] bundled_plugins_marketplace_resolve_failed errorCode=EBUSY errorMessage="EBUSY: resource busy or locked, rmdir '%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\extension-host\windows\x64'"
2026-06-16T04:17:19.674Z info [bundled-plugins] bundled_plugins_reconcile_completed hasExternalPluginStateSync=true reason=startup

After that reconcile failure, the generated marketplace was left partially populated:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins
└── chrome

The generated copies of browser, computer-use, latex, and sites were missing, including required files such as:

• browser/.codex-plugin/plugin.json
• browser/scripts/browser-client.mjs
• computer-use/.codex-plugin/plugin.json
• computer-use/scripts/computer-use-client.mjs

The installed package source was intact and contained all bundled plugins:

C:\Program Files\WindowsApps\OpenAI.Codex_26.609.9530.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins
browser
chrome
computer-use
latex
sites

The lock holder was a running Chrome native host process from the user plugin cache:

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

A non-destructive local repair confirmed the diagnosis: copying the missing plugin folders from the installed package back into the generated marketplace, while leaving the locked chrome/extension-host directory alone, restored the surfaces. After that:

• generated Computer Use client: sky.list_apps() returned 40 apps
• generated Browser client: connected as iab
• Chrome/Comet bridge: connected as extension

Expected behavior: bundled plugin reconcile should tolerate a running Chrome native host, or isolate that failure so one locked Chrome directory cannot leave the generated marketplace missing Browser/Computer Use/LaTeX/Sites. Reconcile should either skip the locked extension-host subtree, stage atomically, or stop/restart the native host before replacing it.

I traced the public repo side of this failure and prepared a tested mitigation branch, but I cannot open an upstream PR from this account because GitHub rejects CreatePullRequest against openai/codex for this user. Leaving the patch here so a maintainer or someone with PR permission can cherry-pick it or open the upstream PR.

Patch:

• Branch: https://github.com/CyrusAuyeung/codex/tree/codex/windows-plugin-cache-locks
• Commit: https://github.com/CyrusAuyeung/codex/commit/3f475cbd68b4d43dc694364d98c252dd5901030b
• Compare: https://github.com/openai/codex/compare/main...CyrusAuyeung:codex:codex/windows-plugin-cache-locks?expand=1

Public code paths I found:

• codex-rs/core-plugins/src/store.rs: plugin cache install/replace/remove path.
• codex-rs/core-plugins/src/store_tests.rs: plugin cache unit tests.
• codex-rs/core-plugins/src/marketplace_upgrade/activation.rs: installed marketplace activation rollback logic.
• codex-rs/core-plugins/src/marketplace_upgrade/activation_tests.rs: added rollback coverage.

Important limitation: the public checkout does not contain the Desktop bundled reconciler symbols from the logs (BundledPluginsMarketplace, bundled_plugins_marketplace_resolve_failed, plugin_marketplace_folder_write_failed, extension-host launch/native-host path generation, etc.). Those appear to live in Desktop/bundled private code. So this patch hardens the public plugin-cache side and adds regression coverage, but the Desktop bundled marketplace staging/reconcile code still needs a private-side fix.

What the patch does:

• Adds bounded Windows retry/backoff around plugin cache remove_dir_all, remove_file, and rename operations when Windows reports lock-like failures (ACCESS_DENIED, sharing violation, lock violation, directory-not-empty).
• Keeps fail-closed behavior: retry exhaustion returns an error, it does not silently ignore the failure.
• Preserves the existing cache root when replacing an existing plugin cache entry cannot proceed because a file is still locked.
• Emits a warning after retry exhaustion so locked-cache failures have explicit telemetry.
• Adds a regression test that installing from a .tmp/bundled-marketplaces plugin source materializes into the stable plugins/cache/<marketplace>/<plugin>/<version> root rather than an active .tmp path.
• Adds Windows tests for transient and persistent file locks around an existing cache entry.
• Adds marketplace activation rollback coverage for post-activation failures.

What still needs to happen in Desktop/private code:

• The bundled marketplace reconcile should stage into a unique directory, validate marketplace.json and required plugin.json files, then atomically switch only after validation succeeds.
• If deleting/replacing the old runtime marketplace fails on Windows because extension-host.exe or a loaded native module still holds a handle, the old usable runtime marketplace should remain active.
• The plugin cache should never activate a latest/active root that points into .tmp/bundled-marketplaces.
• A locked Chrome extension-host subtree should not leave Browser / Computer Use / LaTeX / Sites missing from the generated marketplace.

Validation run on Windows:

• just fix -p codex-core-plugins
• Passed with an existing unrelated clippy::large_enum_variant warning in core-plugins/src/manifest.rs.
• just test -p codex-core-plugins
• 247 tests passed, including the new Windows lock tests and .tmp cache-root regression.
• git diff --check
• Passed.

Bundled plugin reconcile should be atomic and receipt-driven. Stage to a new directory, verify manifest and helper paths, swap by rename, and keep the previous good marketplace if cleanup hits EBUSY. A reconcile receipt with plugin, source version, lock holder if known, status, and rollback path would keep one Chrome host handle from removing unrelated tools.

---

_Generated with ax._

I maintain WinBridge Recovery, an independent Windows recovery tool for Codex Desktop: https://github.com/zemeng5208/winbridge-recovery

This is a strong match for the local-state recovery path the project handles. v3.1.1 already closes Chrome/Edge before repair, stops known Codex/browser helper processes, refuses to enter destructive replacement if targets are still locked, stages replacement content separately, validates it, and uses atomic swaps + rollback/backups for the marketplace/cache state. It also validates plugin versions, latest, runtime paths, and Native Host state after recovery.

The important part of this report is that killing a process name once is not enough when Chrome can immediately respawn the Native Messaging host. I am tracking more precise lock-owner diagnostics (PID / executable path / command line and path-based ownership) so the recovery flow can distinguish the Codex Chrome host from unrelated node.exe/browser processes instead of using broad process-name kills.

So if the failure is EBUSY / os error 5 leaving openai-bundled partial or the plugin cache/latest inconsistent, WinBridge is intended to help recover that state from the official installed package. It does not attempt to fix model-side Chrome routing or other upstream runtime behavior, and it will stop rather than force a swap while a target remains locked.