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

Environment

OS: Windows 11 Home
Codex: Microsoft Store edition, currently 26.602.4764.0
Affected plugins: browser@openai-bundled, computer-use@openai-bundled
Occurrences: 3 times across versions 26.527.x → 26.601.x → 26.602.x

Summary

After every MS Store auto-update of Codex Desktop, the browser and computer-use bundled plugins become unavailable. The chrome plugin survives. The root cause is a
multi-link cascade failure in how Codex syncs the openai-bundled marketplace from the app package to the runtime cache.

Root Cause Chain

Incomplete marketplace extraction

After an update, the runtime marketplace source at:
%USERPROFILE%.codex.tmp\bundled-marketplaces\openai-bundled
is supposed to mirror the app package at:
C:\Program Files\WindowsApps\OpenAI.Codex__x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled
The app package contains 5 plugins: browser, chrome, computer-use, latex, sites. However, after extraction, the .tmp source only contains chrome/extension-host/ —
the other 4 plugin directories are missing entirely. The marketplace manifest (.agents/plugins/marketplace.json) is also absent.

This causes Codex to see no source for browser/computer-use and either disable them or fail to load them.

Stale plugin version cache

The cached plugins at %USERPROFILE%.codex\plugins\cache\openai-bundled\ retain the old version (e.g., 26.601.21317) while the app is now 26.602.x. The latest
pointers for browser/computer-use are missing or broken after the sync failure.

Configuration staleness (ripple effect)

chrome-native-hosts.json: codexCliPath, nodePath, nodeReplPath, resourcesPath still reference old app binary hashes and old app package paths
config.toml: marketplace source points to the incomplete .tmp directory
.codex-global-state.json: electron-chrome-extension-sync-managed-plugin-ids only contains chrome@openai-bundled, omitting browser/computer-use

Self-reinforcing cycle

On restart, Codex re-syncs from the broken .tmp source, sees no browser/computer-use, and the plugins remain unavailable indefinitely — until manual intervention.

Reproduction

Let MS Store auto-update Codex (or install a newer Store version)
Open Codex
Check Settings → Plugins: browser and computer-use are unavailable
chrome plugin still works

Manual Workaround

Replace the .tmp marketplace with a junction to the app package:
mklink /J %USERPROFILE%.codex.tmp\bundled-marketplaces\openai-bundled "C:\Program
Files\WindowsApps\OpenAI.Codex__x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled"
Copy the missing plugin dirs to cache, update latest pointers
Fix chrome-native-hosts.json paths and pluginVersion
Add browser@openai-bundled and computer-use@openai-bundled to electron-chrome-extension-sync-managed-plugin-ids in global state
Restart Codex

Suggested Fixes

Complete marketplace extraction: Ensure ALL plugins from the app package are extracted to .tmp, not just chrome
Include .agents/plugins/marketplace.json: This manifest is critical for plugin discovery
Auto-repair on version mismatch: If the plugin cache version doesn't match the app version, trigger a full re-sync from the app package
Centralize version references: Avoid scattering app version and binary hash paths across 4 separate config files

Timeline

┌───────┬──────────────────────────┬─────────────────┐
│ Date │ From → To │ Trigger │
├───────┼──────────────────────────┼─────────────────┤
│ Jun 1 │ 26.527.7698.0 → ? │ MS Store update │
├───────┼──────────────────────────┼─────────────────┤
│ Jun 2 │ ? → 26.601.x │ MS Store update │
├───────┼──────────────────────────┼─────────────────┤
│ Jun 6 │ 26.601.x → 26.602.4764.0 │ MS Store update │
└───────┴──────────────────────────┴─────────────────┘

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

Bundled plugins (chrome, browser, computer-use) become unavailable after Microsoft Store auto-update #25878
Codex App (Windows/MSIX): bundled plugin reconcile only unpacks "chrome" — computer-use/browser silently dropped ("no longer exists in discovered marketplaces") #26692
Windows desktop upgrade leaves openai-bundled marketplace partial, causing Browser/Computer Use unavailable #26501
Codex Desktop Windows: bundled marketplace rebuild can be blocked by Chrome native host, breaking Computer Use pipe startup #26785
Bundled marketplace under .tmp is repeatedly overwritten with incomplete contents, causing Chrome plugin to fail loading #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:

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.
%USERPROFILE%\.codex\config.toml keeps the previous absolute package path as the openai-bundled marketplace source.
The configured source no longer exists, while the new package contains a valid bundled marketplace and Computer Use client.
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.
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:

avoided persisting versioned WindowsApps/cache paths in user config when they are expected to rotate after updates, or
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.

New Windows Store data point: this failure chain is still present on 2026-08-30 with Codex AppX 26.825.6671.0.

The managed bundled source contains Browser/Chrome manifests for 26.825.51511, but the installed cache contains Browser 26.727.40816 and Chrome 26.727.40816 / 26.825.32147. The expected module consequently fails to import from:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\browser\26.825.51511\scripts\browser-service.mjs

The important path evidence is:

[marketplaces.openai-bundled] is configured as /mnt/c/Users/<user>/.codex/.tmp/bundled-marketplaces/openai-bundled even though the active CLI is Windows-native.
A normal codex plugin marketplace list omits openai-bundled entirely.
A read-only -c override to the equivalent C:\Users\<user>\... source makes the marketplace appear immediately, proving that the managed payload is present and readable.
Reinstalling Browser/Chrome through Settings > Computer Use did not materialize the advertised version into the cache.

There is now a visible downstream symptom in ChatGPT Chrome extension 1.2.27268.51612:

Codex app-server manifest entry is missing required path nodePath

The extension is installed/enabled and its native-host registry/JSON exist. Codex's chrome-native-hosts-v2.json still contains only stale historical runtime targets and no current 26.825 registration.

This supports the diagnosis in the issue: the Store update is not atomically reconciling the bundled marketplace registration and versioned cache. It also shows that the same mismatch cascades into the browser native-host/app-server bootstrap rather than remaining only a missing-plugin UI problem.

Adding another independent Windows recurrence observed on 2026-09-06. This appears to be the same bundled-plugin reconciliation failure, with one useful control result: the current Computer Use runtime remains functional when the stale cached skill is bypassed.

Environment

Windows 11 Pro, x64, build 26200
Active Codex Microsoft Store/AppX package: 26.901.6511.0
App release reported in the desktop log: 26.901.51231
Computer Use plugin bundled with the active AppX package: 26.901.51231
Computer Use plugin selected from the user cache: 26.715.31251
Bundled Computer Use runtime: cua_node runtime archive 0.0.9

All user-specific paths, account information, process IDs, task/thread IDs, named-pipe identifiers, and unrelated configuration values have been omitted.

Observed state

The active AppX package contains the current Computer Use plugin at version 26.901.51231. Its bundled SKILL.md documents the current initialization path:

const { sky } = await import("@oai/sky");

However, Codex injected the older cached Computer Use plugin from:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\computer-use\26.715.31251

That older skill instructs the agent to load scripts/computer-use-client.mjs and call setupComputerUseRuntime(...).

Following the injected instructions fails deterministically with:

Windows Computer Use Sky runtime is unavailable

Resetting the JavaScript session and repeating the documented initialization produces the same error.

Native service status

The desktop log indicates that the native Computer Use service itself initialized successfully:

[computer-use-native-pipe] computer-use notify config ensure finished platform=win32 status=repaired
[computer-use-native-pipe] computer-use native pipe startup ready platform=win32

The named-pipe identifier has been removed from this report.

This suggests that the failure occurs before normal Computer Use operations, in the plugin/skill selection and initialization path rather than in the Windows native helper.

Control test using the current bundled entry point

Bypassing the stale cached skill and following the 26.901.51231 AppX-bundled instructions succeeds:

const { sky } = await import("@oai/sky");

Verified behavior after using the current entry point:

sky.list_apps() completed successfully.
Windows Calculator was launched.
sky.list_windows() returned the Calculator window.
sky.get_window_state() captured the target window successfully.
Computer Use clicks entered 7 + 8 =.
The final captured Calculator state displayed 15.

No Computer Use package, runtime, configuration, permission, or Windows setting was modified to obtain this result.

Impact

Multiple Codex tasks can incorrectly conclude that Computer Use is unavailable because they receive and follow an incompatible cached SKILL.md, even though:

the current AppX package contains a newer matching Computer Use plugin;
the native Computer Use service is ready;
the current @oai/sky entry point works;
end-to-end Windows application control succeeds.

Restarting only the persistent JavaScript session does not repair the stale plugin selection.

A related stale Browser cache symptom was also present: the desktop log reported a missing extension-ids.json beneath an older openai-bundled\browser\26.715.31251 cache path. This may indicate a broader bundled-marketplace/cache reconciliation failure rather than isolated corruption of Computer Use.

Possible local trigger

A legacy non-Store Codex installation remains on disk, and the stale cached plugin version matches that older installation.

This may be a machine-specific trigger, but the active 26.901 Store app should not select an incompatible cached bundled plugin when its own package contains the matching current version. If mixed installation history is relevant, the startup reconciliation path should either replace the stale cache or report an explicit version mismatch.

Expected behavior

On startup or after a Store update, Codex should:

reconcile openai-bundled against the active AppX package;
select the Computer Use plugin and skill matching the current app/runtime;
atomically refresh stale cache entries and latest pointers;
avoid injecting instructions from an incompatible prior plugin version;
surface an explicit plugin-version mismatch if reconciliation cannot complete.

This recurrence suggests that the issue remains present in the 26.901 release line, although the underlying Computer Use runtime itself is operational.

Follow-up from the same Windows environment: the browser integration is now working, and the final recovery provides additional evidence that this is a two-stage registration/reconciliation failure rather than a failure of the underlying Computer Use runtime.

Failure progression

Chrome and Edge initially showed:

Native transport disconnected

The browser extensions were installed, but the Native Messaging Host registration was missing or unusable. The two chrome-native-hosts-v2.json registration files checked on this installation contained:

{"schemaVersion":2,"entries":[]}

After restoring the native-host connection, the side panel progressed to a second, more specific error:

No compatible Codex app-server entry was found

Restarting the desktop app and repairing the browser extension did not regenerate usable app-server entries.

Recovery

The issue was resolved by rebuilding both v2 registration files with schema-v2 entries that referenced only the currently installed Codex runtime and browser-client files, then restarting the affected browser native-host process. No operating-system reinstall, browser reinstall, or account change was required.

This closely resembles the failure modes reported in #28950 and #42520, while the successful recovery mechanism is similar to #40357.

Post-repair verification

Chrome connected to the Codex desktop app.
The Chrome integration created an ephemeral tab, navigated to https://example.com, and read the page content successfully.
Edge connected to the Codex desktop app.
Computer Use remained operational end to end; Windows Calculator was controlled and produced the expected result for 7 + 8 = 15.

The evidence suggests that an update/reconciliation path can leave two independently broken layers:

Native Messaging Host installation/registration.
Codex app-server discovery entries in chrome-native-hosts-v2.json.

Repairing only the first layer changes the visible error but does not restore browser control. The updater/startup reconciliation likely needs to validate and atomically refresh both layers against the active bundled-plugin/runtime version.

All usernames, absolute filesystem paths, account information, process IDs, task/thread identifiers, named-pipe identifiers, registry data beyond the generic component names, and unrelated configuration values have been omitted.

Navigation Menu

Repository navigation

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

Environment

Observed state

Native service status

Control test using the current bundled entry point

Impact

Possible local trigger

Expected behavior

Failure progression

Recovery

Post-repair verification

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

github-actions commented on Jun 6, 2026

dmiedog commented on Jun 7, 2026

goodneamtakenbydogs commented on Jun 16, 2026

wangxinyu666 commented on Jun 24, 2026

codeOct commented on Jun 24, 2026

zemeng5208 commented on Aug 12, 2026

siweigong309-create commented on Aug 24, 2026

th3nolo commented on Aug 30, 2026

g1331 commented on Sep 6, 2026

Environment

Observed state

Native service status

Control test using the current bundled entry point

Impact

Possible local trigger

Expected behavior

g1331 commented on Sep 6, 2026

Failure progression

Recovery

Post-repair verification

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions