Bundled plugins (browser/computer-use) silently break after every MS Store auto-update — incomplete marketplace sync + stale config cascade

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

• #25878
• #26692
• #26501
• #26785
• #25780

Powered by Codex Action

Adding another Windows data point from issue #26864 before closing it as a duplicate.

Environment observed:

• Windows Codex Desktop package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Bundled plugin version: 26.527.31326
• Affected marketplace: openai-bundled

Interesting detail in this case: ~/.codex/config.toml still had a [marketplaces.openai-bundled] entry and the referenced runtime-generated marketplace path existed:

[marketplaces.openai-bundled]
source_type = "local"
source = '\\?\C:\Users\<user>\.codex\.tmp\bundled-marketplaces\openai-bundled'

The local cache also still contained the bundled plugin files for browser, chrome, and computer-use, and the MSIX app package contained app\resources\plugins\openai-bundled.

However, before the workaround, codex plugin marketplace list did not include openai-bundled at all. It only listed openai-primary-runtime and openai-curated.

A lighter workaround restored it immediately:

& "$env:LOCALAPPDATA\OpenAI\Codex\bin\<hash>\codex.exe" plugin marketplace remove openai-bundled
& "$env:LOCALAPPDATA\OpenAI\Codex\bin\<hash>\codex.exe" plugin marketplace add "C:\Program Files\WindowsApps\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled"

After that, codex plugin marketplace list showed openai-bundled, and codex plugin list showed:

browser@openai-bundled       installed, enabled  26.527.31326
chrome@openai-bundled        installed, enabled  26.527.31326
computer-use@openai-bundled  installed, enabled  26.527.31326

One extra note: invoking codex.exe through the WindowsApps package path failed with access denied from this shell, but using the %LOCALAPPDATA%\OpenAI\Codex\bin\...\codex.exe copy worked.

Adding one smaller instance that may fit this stale-config cascade.

In my Windows repro, after an update, a configured Codex CLI path pointed to an old hash directory that no longer existed. I found the stale value in both config.toml (CODEX_CLI_PATH) and chrome-native-hosts-v2.json (paths.codexCliPath). That caused Codex app-server startup / Browser policy config reads to fail.

The confusing part was the final Browser-facing error: it looked like an enterprise network policy block, even though the actionable root cause was a missing configured codex.exe path. This may be another place where version/hash path regeneration or validation after update would help.

Focused write-up: #28474

Additional reproducible evidence from Windows 11 (Microsoft Store Codex Desktop), observed across three consecutive daily upgrades:

| Date | Installed Codex package | Stale [marketplaces.openai-bundled].source still pointed to | Current Computer Use plugin |
|---|---|---|---|
| 2026-06-22 | 26.616.6631.0 | removed 26.609.3341.0 package directory | 26.616.51431 |
| 2026-06-23 | 26.616.9593.0 | removed 26.616.6631.0 package directory | 26.616.71553 |
| 2026-06-24 | 26.616.10790.0 | removed 26.616.9593.0 package directory | 26.616.81150 |

On every update:

1. Microsoft Store installs the new package under a new versioned C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0 directory and removes the previous directory.
2. %USERPROFILE%\.codex\config.toml keeps the previous absolute package path as the openai-bundled marketplace source.
3. The configured source no longer exists, while the new package contains a valid bundled marketplace and Computer Use client.
4. The Computer Use plugin remains marked enabled = true, but the active session does not expose its required model-facing execution tool, so Computer Use is unavailable.
5. The plugin cache contains only prior Computer Use versions until it is repaired manually.

A manual repair consistently restores functionality after a full app restart:

• update [marketplaces.openai-bundled].source to the current AppX InstallLocation\app\resources\plugins\openai-bundled;
• copy the current bundled Computer Use plugin into %USERPROFILE%\.codex\plugins\cache\openai-bundled\computer-use\<plugin-version>;
• restart Codex.

Copying from WindowsApps with ordinary PowerShell Copy-Item can fail with The specified file could not be encrypted; xcopy /G succeeds, which may be relevant to the marketplace sync failure.

This machine is using the normal official configuration (no persistent custom marketplace, junction, or scheduled repair). The failure returns after every Store upgrade.

Suggested additional fix: do not persist a version-specific WindowsApps path without reconciling it on every launch/update. Resolve the current AppX InstallLocation dynamically or stage the bundled marketplace at a stable user-writable path, then atomically refresh the plugin cache before Computer Use tool registration.

Additional Windows data point from Codex Desktop on 2026-06-24.

I am seeing a similar version-skew state after updates, even when the paths currently still exist and the plugins are still usable:

• config.toml has [marketplaces.openai-bundled].source pointing at:

\\?\C:\Program Files\WindowsApps\OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled

• the same config.toml has runtime/app-related values showing:

BROWSER_USE_CODEX_APP_VERSION = "26.616.81150"
CODEX_CLI_PATH = C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\38dff8711e296435\codex.exe

• the installed plugin cache has openai-bundled plugin versions at:

browser 26.609.41114
chrome 26.609.41114
computer-use 26.609.41114

• openai-curated points to:

C:\Users\<user>\.codex\.tmp\plugins

• openai-primary-runtime points to:

C:\Users\<user>\.cache\codex-runtimes\codex-primary-runtime\plugins\openai-primary-runtime

All of the checked paths currently exist, so this is not a hard broken-path state at the moment. The concern is that there are at least three independent version/source identities in play at once: WindowsApps package version, app/runtime metadata version, and plugin cache version. That makes it hard to tell which source is authoritative after an update, and it seems like a plausible path into the stale config / missing plugin cascade described in this issue when an old package/cache is later removed.

It would help if Codex either:

1. avoided persisting versioned WindowsApps/cache paths in user config when they are expected to rotate after updates, or
2. performed a startup reconciliation/repair step that rewrites stale marketplace/plugin paths to the currently installed package/cache before loading plugins.

I maintain WinBridge Recovery, an independent Windows recovery tool for exactly this class of Codex Desktop update-state drift: https://github.com/zemeng5208/winbridge-recovery

This report is a particularly close match to what the tool checks. It compares the currently installed official Desktop package with the user-side openai-bundled marketplace/cache state, repairs incomplete or stale marketplace materialization, reconciles versioned plugin caches and latest pointers, and refreshes runtime / registration state when an app update leaves old paths behind.

A couple of scope notes so this is not mistaken for an upstream fix: WinBridge Recovery only rebuilds/reconciles state from the official package already installed on the machine. It does not patch WindowsApps, redistribute OpenAI plugin files, or bypass security/account/region policy. If the failure is the update cascade described here (partial .tmp marketplace + stale cache/pointers/registration), it is a good candidate for recovery; if a current bundled plugin/runtime itself is incompatible, that still needs an upstream Codex fix.

The project includes backup/rollback and post-repair consistency checks, so it may also be useful as a reproducible diagnostic path for users who otherwise have to repeat the manual repair steps after every Store update.

Additional recurrence observed on 2026-08-21:

• Microsoft Store/AppX registered OpenAI.Codex 26.818.2441.0 over the previously working 26.803.5235.0 package and removed the older package
• After the update, the app package and the available Browser/Chrome/Computer Use plugin/runtime versions were no longer aligned, and the browser-control tool entry disappeared
• Restoring the exact older app/plugin/runtime combination recovered browser control immediately
• Store AutoDownload policy was already set to 2. Local events also showed Codex/ChatGPT update-check calls and Windows Update scans, but the available evidence does not conclusively identify which component initiated the original download

This suggests the Windows update/reconciliation path can still activate a newer app package without a matching, usable Browser toolchain. Atomic app/plugin/runtime activation, or startup repair with a clear version-mismatch error, would prevent this failure mode.