Windows: focus-triggered bundled_plugins_reconcile uninstalls installed plugins when marketplace materialization partially fails (copyfile UNKNOWN)

Open 💬 3 comments Opened Jul 26, 2026 by lost9999

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Version / OS

Codex Desktop (Windows, MS Store MSIX): 26.721.4979.0
Windows 11 Pro for Workstations 10.0.26200

Summary

bundled_plugins_reconcile runs on every app startup and window focus. On this machine the marketplace re-materialization step randomly fails while copying the bundled marketplace out of the MSIX package directory (UNKNOWN: unknown error, copyfile — a different file fails each run: browser/.codex-plugin/backend-specific-skill.md, latex/.codex-plugin/plugin.json, chrome/.codex-plugin/backend-specific-skill.md, …). The staging folder ends up with 5 of the 7 shipped plugins and bundled_plugins_marketplace_resolve_failed is logged.

The reconcile then treats that failed, partial materialization as authoritative and uninstalls the installed bundled plugin that didn't make it into the partial set:

09:49:19.593Z warning [BundledPluginsMarketplace] plugin_marketplace_folder_write_failed errorCode=UNKNOWN errorMessage="UNKNOWN: unknown error, copyfile 'C:\Program Files\WindowsApps\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled\plugins\chrome\.codex-plugin\backend-specific-skill.md' -> 'C:\Users\...\.codex\.tmp\bundled-marketplaces\openai-bundled.staging-288237e3-...\plugins\chrome\.codex-plugin\backend-specific-skill.md'" ... pluginCountAfterWrite=5
09:49:19.602Z warning [BundledPluginsMarketplace] bundled_plugins_marketplace_resolve_failed ...
09:49:19.602Z info    [BundledPluginsMarketplace] bundled_plugin_uninstall_requested pluginId=deep-research@openai-bundled pluginName=deep-research reason=not_in_bundled_marketplace_plugin_names
09:49:19.653Z info    [AppServerConnection] plugin_uninstall_succeeded pluginId=deep-research@openai-bundled

Net effect: the user installs Deep Research from the marketplace UI, and it is silently uninstalled (config entry + plugin cache removed) the next time the window gains focus. Repeats forever. The plugin's source files are fully present in the package resources — app/resources/plugins/openai-bundled/plugins/ contains all 7 plugins including deep-research.

What I ruled out

Package location: reproduced identically with the package junctioned to another NTFS drive and after moving it back to a physical C:\Program Files\WindowsApps location via Settings → Move.
Source corruption: all 7 plugin folders and the failing files are present and readable; copying the same files from a normal user shell succeeds repeatedly.
Third-party config managers were eliminated by watching config.toml writes with a diff logger — the delete is performed by the app at the exact plugin_uninstall_succeeded timestamp.

Expected behavior

If marketplace materialization or resolve fails (bundled_plugins_marketplace_resolve_failed), the reconcile should fail safe and skip the uninstall pass (or reuse the last successfully resolved plugin-name set) instead of uninstalling installed plugins based on a known-bad partial listing.

Possibly related

#26429, #26296, #30270 (plugins disappearing after restart/update) — different trigger paths, but the same fail-destructive reconcile may be the common factor.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

#34244

Powered by Codex Action

lost9999 · 1 month ago

Not a duplicate of #34244 in symptom or effect: that report is a ~61s UI freeze while plugin/list blocks during reconcile (performance), while this one is about the reconcile committing a destructive action — uninstalling an installed bundled plugin — based on a materialization pass that had just logged plugin_marketplace_folder_write_failed + bundled_plugins_marketplace_resolve_failed. They may well share the flaky MSIX copy as a trigger, but the bug reported here is the fail-destructive decision (bundled_plugin_uninstall_requested reason=not_in_bundled_marketplace_plugin_names from a known-bad plugin-name set), which persists across restarts and re-installs. Leaving both open seems right; happy to consolidate logs into #34244 if a maintainer prefers.

zemeng5208 · 16 days ago

Disclosure: I maintain WinBridge Recovery, an independent/non-official Windows recovery utility for Codex Desktop.

This report highlights a recovery rule that is easy to miss: once marketplace materialization/resolve has failed, the resulting plugin-name set should be treated as untrusted. Using that partial set to remove otherwise valid installed plugins turns a transient copy error into persistent local state damage.

WinBridge Recovery approaches the aftermath from the opposite direction: it resolves the currently installed official Codex package, compares the expected bundled plugin state with the managed marketplace/cache, backs up existing user-side state, and only repairs when the source and required manifests can be validated. A failed/incomplete source check is a reason to stop, not a reason to delete more state.

It cannot prevent Desktop itself from running a fail-destructive reconcile, so this is not an upstream fix. But if a bundled plugin has already disappeared because a partial marketplace was treated as authoritative, the project may be useful for diagnosing and restoring the local bundled state without modifying WindowsApps or weakening security policy.