[Windows] Clean bundled-state reset does not bootstrap the managed openai-bundled marketplace

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.5229.0 (Microsoft Store MSIX package OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0)

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64 (Windows 11 Pro)

What issue are you seeing?

After Codex Desktop updates, the managed openai-bundled marketplace can remain on an older app/plugin version. More importantly, removing the stale managed marketplace state does not reliably trigger a clean bootstrap from the currently running MSIX package.

I tested the expected recovery path by fully quitting Codex Desktop and Chrome, backing up the existing state, and moving aside only the openai-bundled registration, installed bundled-plugin entries, managed marketplace directory, and bundled plugin cache. On the next clean Desktop start, Codex did not create a new managed marketplace, did not install the bundled plugins, and did not create a new staging directory during the observed startup. Browser, Chrome, Computer Use, and LaTeX therefore remained unavailable.

The current application package does contain a complete bundled marketplace. Its Browser, Chrome, and Computer Use plugin versions are 26.818.41509. The package marketplace contained 826 files in this installation.

A one-time manual recovery succeeded only after the current package marketplace was copied to a user-writable stable directory, decrypted/materialized, verified file-by-file with SHA256, registered as openai-bundled, and the four bundled plugins were installed again. This shows that the packaged plugin payload is usable and that the failure is in automatic bootstrap/materialization or its startup gating.

Impact:

• Updating Codex Desktop can leave bundled plugins on an old version.
• Removing the stale snapshot does not guarantee that Desktop rebuilds it.
• The Plugins UI can show the bundled plugins unavailable or fail before a usable install can begin.
• There is no documented setting or supported repair action that forces bundled-marketplace bootstrap.

What steps can reproduce the bug?

This was reproduced on a Microsoft Store installation after an app update:

1. Update Codex Desktop to 26.818.5229.0 while an older managed openai-bundled marketplace/cache exists.
2. Fully quit Codex Desktop, including its tray process, and quit Chrome so the native extension host is not holding plugin files.
3. Back up the following state.
4. Remove or move aside only:

• [marketplaces.openai-bundled] from ~/.codex/config.toml;
• the installed entries for browser@openai-bundled, chrome@openai-bundled, computer-use@openai-bundled, and latex@openai-bundled;
• ~/.codex/.tmp/bundled-marketplaces/openai-bundled;
• ~/.codex/plugins/cache/openai-bundled.

1. Start Codex Desktop and wait for startup/plugin reconciliation to finish.
2. Inspect the config and the two directories above.

Observed during the clean-reset test:

• no new [marketplaces.openai-bundled] registration;
• no new managed openai-bundled directory;
• no new openai-bundled plugin cache;
• no newly installed bundled-plugin entries;
• no new openai-bundled.staging-* directory created during that startup;
• bundled plugins remained unavailable.

Restoring the backup and performing the verified one-time manual materialization/install recovered the plugins.

What is the expected behavior?

On Desktop startup, if the managed bundled marketplace is missing, invalid, partial, or from a different application package version, Codex should:

1. discover the bundled marketplace in the currently running application package;
2. materialize it atomically into the managed per-user directory;
3. use a byte-stream copy fallback on Windows when native copyfile cannot copy EFS/Application-Protected package files;
4. validate the completed snapshot before plugin reconciliation;
5. register the managed marketplace and restore/install the bundled plugins expected for the current app version;
6. preserve the last known-good marketplace and installed plugins if materialization fails; and
7. surface an actionable error with a supported Retry/Repair operation instead of leaving the marketplace absent.

Additional information

This report is related to, but differs from, several existing reports:

• #25220 and #32589 report copyfile failures on EFS-protected WindowsApps resources. In this clean-reset test, no new staging directory appeared at all, so the startup path may also exit or be gated before the copy attempt.
• #33738 reports a managed marketplace snapshot remaining stale after an app update. This report adds that deleting/moving aside the stale snapshot does not reliably bootstrap a replacement.
• #35472 reports destructive reconciliation after partial materialization. The requested fail-safe behavior here is consistent with that report.
• #30270, #26501, and #26692 cover stale or partial marketplaces after updates, but their recovery paths normally rely on a subsequent rebuild. Here, the rebuild did not start from a clean bundled state.

Package-file observations:

• The current MSIX marketplace source was present and readable.
• The source contained 826 files.
• Files copied through the successful recovery path were decrypted and all 826 files matched the source by SHA256.
• The recovered marketplace successfully installed Browser, Chrome, and Computer Use 26.818.41509, confirming that the package payload itself was valid.

No WindowsApps files, native-host registry entries, manifests, or latest junctions were modified during the clean-reset reproduction.