Bundled Browser/Chrome/Computer Use plugins disappear after Windows app updates due to stale bundled marketplace path

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

• #28703
• #30259

Powered by Codex Action

I reviewed the suggested duplicates.

This looks related to #28703 and possibly the same Windows bundled-plugin reconciliation/update family of bugs, but I am keeping this issue open for now because it adds a more specific update-path diagnostic:

• after Codex updates, [marketplaces.openai-bundled].source can remain pointed at an older versioned OpenAI.Codex_<version> WindowsApps path;
• .tmp\bundled-marketplaces\openai-bundled\plugins can become incomplete;
• the current app package still contains valid browser, chrome, and computer-use bundled source manifests;
• updating the source path and rebuilding/restoring bundled marketplace temp/cache restores the plugins.

#30259 appears related but is already closed and was less specific about the stale bundled marketplace source path.

I pushed a candidate fix to my fork for this stale bundled-marketplace update path.

Compare: https://github.com/openai/codex/compare/main...Nicolas0315:codex:codex/bundled-marketplace-source-refresh
Commit: Nicolas0315/codex@7c0e9d74799fbc8a67de2fcbbf721c8d4c4ec5e8

What changed:

• openai-bundled / openai-bundled-alpha configured roots now keep using the configured source when it still has a manifest, but fall back to the managed .tmp/bundled-marketplaces/<name> cache when the persisted local source no longer has a marketplace manifest.
• codex plugin marketplace add can refresh a changed local source for those reserved bundled marketplace names, so an app package path change is not treated like an ordinary conflicting marketplace.
• Ordinary custom marketplaces still reject same-name/different-source local refreshes.

Validation:

• Local: just fmt, git diff --check, focused codex-core-plugins regression tests 4/4, focused codex-cli snapshot tests 3/3.
• Local full just test -p codex-core-plugins: 296 passed, 1 failed in manager::tests::skills_service_reuses_skills_parsed_during_plugin_load; that failure reproduces standalone here and is due ambient Azure/Lottie skills leaking into this machine's test environment, unrelated to marketplace source handling.
• SSH exact-commit validation:
• cyberagent-mac-m5max: git diff --check HEAD~1 HEAD, focused core tests 4/4, focused CLI tests 3/3 passed.
• nicolas-macbook-pro: git diff --check HEAD~1 HEAD passed; Rust toolchain unavailable on that host.
• nicolas2025: git diff --check HEAD~1 HEAD, focused cargo test -p codex-core-plugins cases 4/4, focused cargo test -p codex-cli cases 3/3 passed.
• rtx5060ti: git diff --check HEAD~1 HEAD passed; Rust compile tests skipped because this host still has the known linker configuration issue that rejects MSVC linker flags.

Boundary: this covers the core side of stale persisted source recovery and source refresh. If Desktop fails to repopulate .tmp/bundled-marketplaces/openai-bundled at all, that packaging/startup copy path still needs to be fixed separately.

Thanks, this looks aligned with the stale persisted source evidence from my repro.

The source-refresh behavior you described should cover the concrete case I reported where [marketplaces.openai-bundled].source remained pointed at an older OpenAI.Codex_<version> WindowsApps path even though the current app package still had valid bundled manifests.

One extra data point from my local repro: after updates, .tmp\bundled-marketplaces\openai-bundled\plugins was sometimes incomplete as well, commonly retaining only chrome. In that state, repairing only the persisted source path was not always sufficient; I also had to restore/rebuild the bundled marketplace temp/cache from the current app source.

So I agree with your boundary note: this candidate fix seems to address the core stale-source/source-refresh side, while a separate Desktop packaging/startup copy path may still need attention if .tmp/bundled-marketplaces/openai-bundled is not repopulated correctly.

Adding another Windows Store update repro from Codex Desktop 26.623.5546.0.

Observed sequence:

• Previous repaired/working app package source: OpenAI.Codex_26.623.4041.0_x64__2p2nqsd0c76g0.
• After updating Codex Desktop, current installed package became: OpenAI.Codex_26.623.5546.0_x64__2p2nqsd0c76g0.
• %USERPROFILE%\.codex\config.toml still had [marketplaces.openai-bundled].source pointing at the old OpenAI.Codex_26.623.4041.0...\app\resources\plugins\openai-bundled path.
• The old 26.623.4041.0 WindowsApps path no longer existed; the new 26.623.5546.0 bundled source existed and contained valid bundled plugins.
• Before repair, codex plugin list failed with:

Error: failed to load configured marketplace snapshot(s):
- `openai-bundled` at \\?\C:\Program Files\WindowsApps\OpenAI.Codex_26.623.4041.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled: marketplace root does not contain a supported manifest

Additional cache/link state from this repro:

• Current app bundled source manifests for browser, chrome, and computer-use were version 26.623.42026.
• Existing local cache still had older bundled plugin version 26.623.31921.
• browser/latest still pointed at ...\browser\26.623.31921.
• chrome/latest still pointed at %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome.
• computer-use/latest eventually pointed at ...\computer-use\26.623.42026 after re-adding the plugin.

Manual repair that restored the plugins:

codex plugin marketplace remove openai-bundled
codex plugin marketplace add "C:\Program Files\WindowsApps\OpenAI.Codex_26.623.5546.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled"
codex plugin add browser@openai-bundled
codex plugin add chrome@openai-bundled
codex plugin add computer-use@openai-bundled

PowerShell Remove-Item hit a null-reference error on some stale latest junctions, so I recreated the latest junctions with a narrower link-only delete via [System.IO.Directory]::Delete($latest, $false) followed by New-Item -ItemType Junction.

Post-repair validation:

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

codex doctor --summary reported 0 fail, and Browser runtime discovery could see both Chrome and Codex In-app Browser.

This confirms the stale versioned WindowsApps marketplace source is still reproducible after a later update. It also adds one extra detail for the fix boundary: startup/update repair may need to validate not only [marketplaces.openai-bundled].source, but also the plugin cache latest junctions, because they can remain pointed at old cache versions or at the transient .tmp\bundled-marketplaces source after the marketplace source is repaired.

I prepared a candidate fix branch for this issue here:

• Branch: https://github.com/xiaokangzaina/codex/tree/codex/refresh-stale-bundled-marketplace
• Compare: https://github.com/openai/codex/compare/main...xiaokangzaina:codex%2Frefresh-stale-bundled-marketplace?expand=1
• Commit: https://github.com/xiaokangzaina/codex/commit/1ff29a6e95ef917a8a43c3577b44291eabee3251

The patch lets managed bundled marketplaces refresh their stale local source path after Windows package updates, and falls back to .tmp/bundled-marketplaces/<name> when a configured bundled local source no longer has a marketplace manifest.

Validation:

• cargo test -p codex-core-plugins marketplace_add
• cargo test -p codex-core-plugins list_marketplaces
• git diff --check

I attempted to open a draft PR from the fork, but the current GitHub token/integration is not permitted to create a PR against openai/codex (Resource not accessible by integration).

Thanks for the additional Windows Store update repro. This matches the stale bundled marketplace source failure mode I reported, and the extra latest junction detail is useful.

I confirmed locally that this is not just a stale [marketplaces.openai-bundled].source problem. After repair, bundled plugin cache links can also remain stale or point back into .tmp/bundled-marketplaces/openai-bundled/plugins/<plugin>, so startup/update recovery should validate and refresh the per-plugin latest link as well as the marketplace source/cache contents.

For the candidate fix: I agree a maintainer-side cherry-pick or a normal manual fork PR would be the right path. The integration-token PR failure looks like a GitHub permission limitation rather than evidence that the patch is not useful.

I prepared a fork branch with a regression-tested fix for this issue, but GitHub returns a CreatePullRequest permission error for this account when targeting openai/codex directly.

Branch: https://github.com/xiaokangzaina/codex/tree/codex/refresh-stale-bundled-marketplace
Compare: https://github.com/openai/codex/compare/main...xiaokangzaina:codex/refresh-stale-bundled-marketplace?expand=1
Commit: https://github.com/xiaokangzaina/codex/commit/92f70c0a580361aa7b16180501247d530c485e67

Summary:

• allow managed openai-bundled marketplaces to refresh from a new local directory source instead of rejecting the same marketplace name after Windows app updates
• fall back to the managed bundled marketplace root when the configured bundled local source points at a stale/missing path
• add regression tests for both stale-source paths

Validation:

• cargo test -p codex-core-plugins marketplace_add::tests::add_marketplace_sync_refreshes_bundled_local_directory_source -- --exact
• cargo test -p codex-core-plugins manager::tests::list_marketplaces_falls_back_to_managed_bundled_root_when_configured_source_is_stale -- --exact
• git diff --check upstream/main...HEAD

Still reproducible after multiple later Windows Store / Desktop updates.

Latest observed repro on Windows Codex Desktop:

• Current running app package: OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0
• Stale [marketplaces.openai-bundled].source before repair still pointed at: OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled
• Current app bundled source exists and contains valid manifests for:
• browser
• computer-use
• Current bundled plugin manifest version: 26.623.141536
• BROWSER_USE_CODEX_APP_VERSION in config also showed 26.623.141536, so the plugin metadata/runtime version matched the current app package, but the persisted marketplace source was still one package behind.
• Manual repair was again only to update [marketplaces.openai-bundled].source to the current package's ...\app\resources\plugins\openai-bundled, then restart Codex.
• node_repl remained healthy (nodeRepl.write('ok') returned ok), so this latest repro was not a node runtime failure.

Recent consecutive local pattern from this machine:

• Current 26.623.4041.0, stale source 26.616.10790.0
• Current 26.623.5546.0, stale source 26.623.4041.0
• Current 26.623.9142.0, stale source 26.623.5546.0
• Current 26.623.11225.0, stale source 26.623.9142.0
• Current 26.623.13972.0, stale source 26.623.11225.0
• Current 26.623.19656.0, stale source 26.623.13972.0

So this is no longer intermittent on this Windows Store install: after each app update, the persisted openai-bundled source remains pointed at the previous versioned WindowsApps package path. The workaround is simple, but it has to be repeated after every update, which effectively leaves Browser / Computer Use unavailable until manual config repair.

Requested fix remains the same: on startup/update, reconcile [marketplaces.openai-bundled].source against the currently running WindowsApps package, or avoid persisting a versioned WindowsApps package path in user config for bundled marketplaces.

This looks like a bundled-marketplace registration freshness boundary, not only a Windows update bug.

The runtime should separate:

plugin was bundled with the app
≠
plugin is currently registered from the active bundled marketplace source

In the report, the active app package changes after update, but the local marketplace config can still point to an older versioned WindowsApps path.

So the useful invariant is:

RegisteredBundledSourceVersion == RunningAppBundledSourceVersion

and:

ExpectedBundledPlugins ⊆ AvailableBundledPlugins

Failure shape:

Codex Desktop updates to a new WindowsApps package
+
[marketplaces.openai-bundled].source still points to an older package path
+
temp/cache is rebuilt or read from stale/incomplete bundled marketplace state
+
browser / computer-use disappear while current app manifests still exist
=>
installed/bundled plugin identity is no longer supported by the active source path

Minimal startup check:

def validate_bundled_marketplace(running_app, config, cache):
expected = {"browser", "chrome", "computer-use"}

source_is_current = (
config["openai_bundled_source_version"]
== running_app["bundled_source_version"]
)

available = set(cache.get("plugins", []))
missing = expected - available

if not source_is_current or missing:
return {
"decision": "repair_bundled_marketplace",
"source_is_current": source_is_current,
"missing_plugins": sorted(missing),
}

return {
"decision": "bundled_marketplace_ready",
"missing_plugins": [],
}

Regression cases:

1. app updates, bundled source path still points to old package

=> re-register current bundled source

1. app updates, temp/cache contains only chrome

=> rebuild bundled marketplace cache from current app source

1. current app manifests exist for browser/chrome/computer-use

• available plugin list lacks browser/computer-use

=> local bundled_marketplace_incomplete diagnostic or auto-repair

1. no app version/path change

• all expected bundled plugins available

=> no repair

1. stale absolute WindowsApps path no longer exists

=> do not silently drop plugins; repair or emit stale_bundled_source_path

The key boundary is:

bundled plugin availability should be derived from the current running app source, not from a stale absolute path persisted across app updates.

If the app package version changes, bundled marketplace registration and cache state should be refreshed atomically before the plugin surface is advertised.

Same issue; Feedback ID: 019f5dac-6042-7652-b369-7a6d9e8da34d

Adding a newer update/recovery instance with the exact source-conflict and uninstall errors.

Environment

• Windows 11 x64
• Microsoft Store package: OpenAI.Codex_26.707.12708.0
• Old bundled plugin/cache version still present: 26.707.61608
• New bundled marketplace/plugin version generated by the update: 26.707.91948
• The Store package was already on drive C: for this update

Confirmed update conflict

A legacy openai-bundled marketplace entry remained in %USERPROFILE%\.codex\config.toml from an earlier manual recovery:

[marketplaces.openai-bundled]
last_updated = "2026-07-09T07:54:16Z"
source_type = "local"
source = '\\?\C:\Users\<user>\.codex\plugins\cache\openai-bundled'

The updated app generated the new managed marketplace at:

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

but startup reconciliation failed with:

marketplace 'openai-bundled' is already added from a different source;
remove it before adding this source

This left old and new bundled-plugin state mixed. The settings UI then showed the in-app Browser as unavailable and omitted Computer Use even though the native backends/pipes could still be present.

Chrome uninstall failure

Three UI uninstall attempts failed with the same log error:

failed to uninstall plugin:
failed to remove existing plugin cache entry:
Access is denied. (os error 5)
pluginId=chrome@openai-bundled

An orphaned Node REPL process was also present: its recorded parent PID no longer existed. This may have held a cache handle, but I did not prove which process owned the denied handle. The error is in the same Windows cache-lock family as #22114, while the reserved-marketplace source collision is independently confirmed by the log above.

Recovery performed

1. Backed up config.toml.
2. Removed only the four-line legacy [marketplaces.openai-bundled] block.
3. Preserved the existing enabled entries for computer-use@openai-bundled and chrome@openai-bundled.
4. Verified that the orphan Node process's parent no longer existed, then terminated only that orphan.
5. Did not manually edit/delete the native-host manifest, registry keys, or plugin cache.
6. Fully exited and restarted Codex.
7. Confirmed that the app automatically registered openai-bundled from the managed .tmp\bundled-marketplaces path.
8. Retried through the plugin UI.

After restart, Browser installation, Chrome uninstall, and Chrome reinstall all succeeded. Browser, Computer Use, and Chrome caches were rebuilt at 26.707.91948. The official Computer Use bootstrap returned connected: true, and the Chrome extension backend connected successfully after Chrome was launched.

Requested behavior

For the reserved bundled marketplace names, an app update should migrate or replace a legacy source registration automatically, or at minimum surface an actionable conflict instead of leaving mixed cache/UI state. Plugin refresh/uninstall should also avoid deleting a cache tree while a bundled runtime/native host/Node worker may still hold it, and should fail without partially materializing the replacement.

This recovery did not fix the separate in-app Browser crash after real-page navigation.