Windows bundled marketplace EBUSY leaves Computer Use unavailable

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

• #27234
• #26785
• #26692
• #28084
• #26792

Powered by Codex Action

Another current reproduction on Windows. This is getting ridiculous: Windows Computer Use should not require users to become local package.json janitors and cache-cleanup operators just to survive normal Codex restarts. The bundled plugin/runtime lifecycle is still leaving the product in a broken state.

This is not just #27287 / the @oai/sky exports mismatch. On this machine the export workaround was already present and verified, but Computer Use still broke after a Codex restart because the native pipe / bundled marketplace / Chrome native-host state got wedged again.

Environment observed:

• Codex Desktop: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
• Computer Use plugin: openai-bundled/computer-use/26.609.41114
• CUA runtime: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\789504f803e82e2b
• @oai/sky: 0.4.10
• The local @oai/sky/package.json already exported:

{
  ".": "./dist/project/cua/sky_js/src/index.js",
  "./dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js": "./dist/project/cua/sky_js/src/targets/windows/internal/computer_use_client_base.js"
}

Observed failure after restart:

Computer Use native pipe is unavailable: Error: failed to connect native pipe: 系统找不到指定的文件。 (os error 2)

Relevant desktop log lines from the same run:

2026-06-17T01:47:55.181Z info [computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-f8331688-7154-438a-adee-551beef5c3dc platform=win32
2026-06-17T01:48:07.511Z warning [BundledPluginsMarketplace] bundled_plugins_marketplace_install_failed ... errorCategory=plugin_cache_windows_file_lock errorMessage="failed to uninstall plugin: failed to remove existing plugin cache entry: 拒绝访问。 (os error 5)" ... pluginName=chrome
2026-06-17T01:48:30.923Z warning [BundledPluginsMarketplace] bundled_plugins_marketplace_install_failed ... errorCategory=plugin_cache_windows_file_lock errorMessage="failed to install plugin: failed to back up plugin cache entry: 拒绝访问。 (os error 5)" ... pluginName=chrome

So the desktop log claimed the Computer Use pipe had started, but the normal Computer Use bootstrap still failed to connect to it. This is exactly the kind of state split a bundled runtime should not expose to users.

Recovery that worked:

1. Stop the stale Chrome native messaging host under %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe.
2. Remove only %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled.
3. Restart Codex Desktop.
4. Re-run the normal Computer Use bootstrap.

Verification after that cleanup-first restart:

sky.list_apps() -> ok, appCount: 40
get_window_state({ include_text: true }) on a real targetable window -> ok, stateRead: true

This is a second failure layer on top of the export mismatch. The durable fix needs to be in the bundled plugin/runtime release path, not in per-user local repairs. At minimum, please add a Windows release smoke test that starts Codex Desktop, invokes Computer Use, runs sky.list_apps(), reads one targetable window with get_window_state(), restarts Codex while the Chrome native host exists, and verifies the same sequence still works.

Since Windows is supposed to be officially supported now, it would be great for there to be a Windows VM smoke test before releasing new app/plugin versions to make sure it at least launches and can do basic functionality. It would be even nicer to do both Windows 10 and 11 in separate smoke tests. Windows support was announced but is definitely not a first-class feature right now.

I posted a tested public-repo mitigation branch and code-path notes in the canonical thread here: https://github.com/openai/codex/issues/27234#issuecomment-4733496317

Short version: I could not open an upstream PR because this account does not have CreatePullRequest permission on openai/codex, but the branch is available for maintainers to cherry-pick or turn into a PR:

• 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

Scope note: the public patch hardens codex-rs/core-plugins plugin-cache replacement on Windows and adds lock regression tests. The Desktop BundledPluginsMarketplace reconciler code that owns the generated bundled marketplace appears to be private, so the full staging/validation fix still needs to happen there.

Disclosure: I maintain WinBridge Recovery, an independent Windows recovery project for Codex Desktop.

The important part of this report for recovery tooling is the split between the trigger and the persistent damage: EBUSY from extension-host.exe / Codex Node workers prevents replacement of the generated bundled marketplace, then the partial marketplace survives and makes Computer Use look unavailable even though the helper/runtime may still be healthy.

WinBridge Recovery is intended to repair that second layer. It validates the current official AppX bundled source against the active managed marketplace, versioned plugin cache and latest pointers, creates a rollback backup, and can rebuild the incomplete user-side state after the locking processes are quiesced.

One useful lesson from this issue that I’m also taking into the project: lock preflight should not look only for extension-host.exe; Codex-owned Node workers can hold native modules from the plugin tree too. I would not recommend killing arbitrary node.exe processes, so any automatic handling should identify only processes tied to the Codex/plugin cache.

This does not fix the upstream lifecycle race itself, but it may make recovery from the partial-marketplace state repeatable instead of manually reconstructing the tree each time.