Codex Desktop Windows: bundled marketplace rebuild can be blocked by Chrome native host, breaking Computer Use pipe startup

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

• #26109
• #26501
• #26692
• #25780
• #25795

Powered by Codex Action

Adding another Windows repro/data point from 2026-06-08 that matches this root-cause chain and shows Computer Use can break after it was already working.

Environment:

• Windows 11 Pro 25H2 / 10.0.26200 x64
• Codex Desktop: OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0
• Installed bundled plugins observed: 26.602.40724
• computer-use@openai-bundled was installed/enabled, and the installed helper existed at the stable plugin cache path

Observed sequence in the Desktop log:

2026-06-08T13:43:26.618Z info [computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-...
2026-06-08T13:43:31.755Z 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-08T13:43:37.266Z info [computer-use-native-pipe] computer-use native pipe helper paths changed
... computer-use notify config ensure finished reason=missing-helper-path status=skipped
... computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable"

After the failure, the generated bundled marketplace under:

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

was partial: it only had plugins\chrome, and was missing .agents\plugins\marketplace.json plus the other bundled plugin directories including plugins\computer-use. The installed app resources were still complete, and the Computer Use plugin cache still contained scripts\computer-use-client.mjs and node_modules\@oai\sky\bin\windows\codex-computer-use.exe.

So this was not an entitlement/availability issue and not a missing helper binary in the installed package. It looks like a transient/generated openai-bundled marketplace corruption after Chrome's native host locked the extension-host\windows\x64 directory.

Local recovery that restored functionality:

• Restored the missing marketplace manifest and missing bundled plugin directories from the installed app bundle.
• Left the locked plugins\chrome subtree in place because the Chrome native host still held it.
• Restarted/recovered Codex Desktop's native pipe state.

Validation after repair:

• codex plugin marketplace list listed openai-bundled again.
• codex plugin list showed computer-use@openai-bundled installed, enabled 26.602.40724.
• Desktop logs showed computer-use native pipe startup ready again.
• A live Computer Use smoke test with setupComputerUseRuntime(...) + sky.list_apps() succeeded and returned 40 apps.

This reinforces the expected fix here: bundled marketplace reconciliation should be atomic/recoverable, and a locked Chrome native-host directory should not invalidate Computer Use helper-path resolution or leave openai-bundled half-materialized.

Additional Windows repro on a newer Codex Desktop build.

Environment observed:

• Windows
• Codex Desktop package: OpenAI.Codex_26.602.9276.0_x64__2p2nqsd0c76g0
• Chrome was running, with multiple extension-host.exe processes under %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\...
• Chrome native messaging pipes existed, but no \\.\pipe\codex-computer-use-* pipe existed.

Failure state:

• %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins was left partial.
• Only a truncated chrome plugin directory was present at one point; browser, computer-use, latex, and the newer sites bundled plugin were missing from the temporary marketplace.
• The stable app resource bundle was complete and contained browser, chrome, computer-use, latex, and sites.
• config.toml had [marketplaces.openai-bundled].source pointing at the temporary marketplace path instead of the installed app resource bundle.

Relevant log pattern matched this issue:

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'"

followed by repeated:

computer-use notify config ensure finished platform=win32 reason=missing-helper-path status=skipped
computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable"

Runtime check after the failure:

{
  "computerUse": {
    "ok": false,
    "message": "Computer Use native pipe is unavailable: Error: failed to connect native pipe: The system cannot find the file specified. (os error 2)"
  },
  "chrome": {
    "ok": true,
    "browserId": "extension"
  }
}

Local recovery that made the state usable again:

1. Point [marketplaces.openai-bundled].source back to the current installed app resource bundle, e.g. %ProgramFiles%\WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled.
2. Rebuild %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled from that resource bundle.
3. Avoid overwriting chrome\extension-host while it is locked; copy the rest of Chrome metadata/scripts and the non-Chrome bundled plugins first, or stop/restart the Chrome native host cleanly.
4. Restart Codex Desktop so the codex-computer-use-* pipe is recreated.

One extra recovery-tooling note: config.toml can contain non-ASCII project paths. Any workaround script that rewrites this file should explicitly read/write UTF-8 and avoid PowerShell's legacy default encoding, otherwise project entries with non-ASCII paths can be corrupted while repairing the plugin source.

I maintain WinBridge Recovery for Windows Codex Desktop local recovery: https://github.com/zemeng5208/winbridge-recovery

This issue is a strong match for the project's file-lock + partial-marketplace recovery path. The important part is the sequence: Computer Use is initially healthy, Chrome's native extension-host.exe keeps a handle open, the bundled marketplace rebuild hits EBUSY, the active marketplace is left without its manifest/other plugins, and Computer Use helper-path resolution then collapses even though the installed package and stable plugin cache still contain the required files.

WinBridge v3.1.1 already avoids repairing directly in-place: it verifies the current AppX/bundled source, checks known Codex/Chrome helper processes and target files before replacement, stages complete marketplace/cache/runtime copies, validates them, then performs an atomic switch with rollback data. It also verifies plugin cache versions/latest and the post-repair Computer Use/Native Host state.

One limitation: precise handle-owner attribution is still an area I am improving. The current tool can detect/prevent unsafe replacement and handle known Codex/Chrome helper processes, but I would not claim it can identify every arbitrary Windows lock holder yet. It also never uses broad taskkill /IM node.exe, changes WindowsApps ACLs, or patches the official package.

For the exact EBUSY -> partial openai-bundled -> missing-helper-path chain documented here, this is directly within WinBridge's intended recovery scope.