Windows desktop upgrade leaves openai-bundled marketplace partial, causing Browser/Computer Use unavailable

Open 💬 6 comments Opened Jun 5, 2026 by D2Rich
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

After recent Codex Windows desktop app upgrades/restarts, Browser and Computer Use repeatedly become unavailable or appear unavailable in settings. Local diagnostics show that Codex can leave the active bundled marketplace directory in a partial/corrupt state:

C:\Users\dzr04\.codex\.tmp\bundled-marketplaces\openai-bundled

The active directory may contain only:

plugins\chrome\extension-host

and is missing:

C:\Users\dzr04\.codex\.tmp\bundled-marketplaces\openai-bundled\.agents\plugins\marketplace.json

When this happens, CLI reports:

No plugins found in marketplace openai-bundled

while the plugin cache still contains installed Browser / Chrome / Computer Use plugin roots.

Environment

  • OS: Windows
  • Codex desktop app observed before update: OpenAI.Codex_26.601.2237.0_x64__2p2nqsd0c76g0
  • Codex desktop app after update: OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0
  • CLI observed before update: Codex Doctor v0.136.0-alpha.2
  • CLI after update: Codex Doctor v0.137.0-alpha.4
  • Bundled plugin runtime observed after update: 26.602.30954
  • Codex home: C:\Users\dzr04\.codex

Impact

  • Settings can show Browser or Computer Use unavailable after restart/update.
  • codex plugin list --marketplace openai-bundled returns no plugins.
  • Computer Use native pipe can fail at startup with missing helper paths.
  • Browser IAB may still be internally available, but marketplace/plugin state exposed to settings/CLI is inconsistent.
  • Manual repairs are not durable across updates/restarts.

Evidence

codex doctor --summary reports config/auth/runtime loaded with no hard failures, e.g.:

15 ok · 1 idle · 3 notes · 2 warn · 0 fail degraded

But:

codex plugin list --marketplace openai-bundled

returns:

No plugins found in marketplace openai-bundled

Observed active marketplace path:

C:\Users\dzr04\.codex\.tmp\bundled-marketplaces\openai-bundled

Observed contents:

plugins

Missing:

C:\Users\dzr04\.codex\.tmp\bundled-marketplaces\openai-bundled\.agents\plugins\marketplace.json

Observed plugin cache still contains installed roots such as:

  • C:\Users\dzr04\.codex\plugins\cache\openai-bundled\browser\26.602.30954
  • C:\Users\dzr04\.codex\plugins\cache\openai-bundled\chrome\latest
  • C:\Users\dzr04\.codex\plugins\cache\openai-bundled\computer-use\26.602.30954

Relevant log messages observed include:

bundled_plugins_runtime_marketplace_written pluginCount=4 pluginNames=["browser","chrome","computer-use","latex"] targetMarketplaceRoot=C:\Users\dzr04\.codex\.tmp\bundled-marketplaces\openai-bundled

Earlier version also produced:

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

Recent version produced:

computer-use notify config ensure finished platform=win32 reason=missing-helper-path status=skipped
computer-use native pipe startup failed errorMessage="Windows Computer Use helper paths are unavailable"

There were also file-operation failures during bundled marketplace rebuild:

EPERM: operation not permitted, rename '...\openai-bundled.staging-...' -> '...\openai-bundled'

Earlier runs also showed EBUSY around Chrome/extension-host files.

Additional observation

The Browser IAB backend itself can still be reachable. Using the Browser plugin client through node_repl, agent.browsers.get("iab") succeeded and listed the current in-app browser tab. This suggests the Browser backend may be running, while marketplace/plugin state is corrupted or unsynchronized.

Reproduction pattern

  1. Use Codex desktop app on Windows.
  2. Enable/use Browser and Computer Use.
  3. Let Codex desktop update, or restart Codex after update.
  4. Open settings for Browser / Computer Use.
  5. Browser or Computer Use may show unavailable.
  6. codex plugin list --marketplace openai-bundled may report no plugins.
  7. Inspect C:\Users\dzr04\.codex\.tmp\bundled-marketplaces\openai-bundled.
  8. The directory may be partial and missing .agents\plugins\marketplace.json.

Suspected root cause

The Codex desktop app appears to rebuild the bundled openai-bundled marketplace under .codex\.tmp\bundled-marketplaces. On Windows, this rebuild can be interrupted or blocked by file locks from extension-host.exe / native messaging host processes, leaving a partial active marketplace. Subsequent plugin/state reads treat openai-bundled as empty or invalid.

There also appears to be a startup ordering issue where Computer Use native pipe initialization can happen before the rebuilt marketplace and installed helper paths are available, causing missing-helper-path.

Workarounds tried

  • Cleaning malformed TOML project headers.
  • Removing invalid project-level .codex/config.toml.
  • Reinstalling browser@openai-bundled, chrome@openai-bundled, and computer-use@openai-bundled.
  • Removing custom fixed marketplace overrides.
  • Killing stale extension-host.exe.
  • Testing CODEX_ELECTRON_ENABLE_WINDOWS_COMPUTER_USE=1.
  • Verifying Browser IAB directly with Browser plugin client.

Some workarounds temporarily restore functionality, but the issue recurs after updates/restarts.

Non-fixes / pitfalls

These should not be required and were not durable:

  • Long-term overriding [marketplaces.openai-bundled] to a custom fixed directory.
  • Relying on openai-bundled-fixed as the primary marketplace.
  • Setting SKY_CUA_SERVICE_PATH or notify to codex-computer-use.exe.

Requested fix

Please investigate Codex desktop bundled marketplace rebuild on Windows:

  1. Ensure .tmp\bundled-marketplaces\openai-bundled is updated atomically and never left as the active marketplace if staging/rename fails.
  2. Detect and recover from partial active marketplace directories missing .agents\plugins\marketplace.json.
  3. Avoid deleting/uninstalling bundled plugin state based on a partial marketplace.
  4. Delay or retry Computer Use native pipe initialization until computer-use@openai-bundled helper paths are available.
  5. Handle native messaging extension-host.exe file locks during upgrade/rebuild.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25780
  • #26109
  • #26387
  • #25878
  • #25220

Powered by Codex Action

kotodamaP · 2 months ago

I also hit a related Windows case and closed my separate report (#27493) as a likely duplicate/related issue.

Additional observation from my case, without local paths or private details:

  • Computer Use did not appear in codex plugin list / plugin UI.
  • The bundled Computer Use cache and skill/runtime files were present locally.
  • A lightweight Computer Use runtime check could still connect to the Windows helper and list installed apps.

So in my case the runtime appeared reachable, while plugin listing/UI reflection still made Computer Use look missing. That seems consistent with a bundled marketplace/plugin-state synchronization issue rather than the helper itself being entirely unavailable.

Orange1006mm · 2 months ago

Reproduced on a newer Windows desktop build with a deterministic lock owner and the same partial marketplace outcome.

Environment

  • Codex Desktop package: OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0
  • Codex CLI: 0.138.0-alpha.7
  • Bundled Browser/Chrome/Computer Use plugin version: 26.608.12217
  • Browser involved in this reproduction: Microsoft Edge, including a background --no-startup-window process
  • Codex extension ID: hehggadaopoacecdllhhajmbjkdcmajg

Observed sequence

  1. After restoring the bundled marketplace and installing browser, chrome, and computer-use, Settings briefly showed Browser and Computer Use normally.
  2. Codex startup reconciliation wrote a valid marketplace and the plugins appeared.
  3. The browser extension started the native host from:

%CODEX_HOME%\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

  1. In this build, the chrome\latest junction was recreated to point directly into the active marketplace:

%CODEX_HOME%\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome

  1. A later startup/focus reconciliation attempted to replace/remove that active marketplace while extension-host.exe was running. Windows rejected the directory removal with EBUSY.
  2. Immediately afterward, Settings lost Browser and Computer Use. The active marketplace contained only plugins\chrome, .agents\plugins\marketplace.json was missing, and codex plugin list --marketplace openai-bundled --available --json returned empty arrays.

Relevant log excerpt, with the user path redacted:

bundled_plugins_reconcile_started hasExternalPluginStateSync=true queued=false reason=startup
bundled_plugins_marketplace_resolve_failed errorCode=EBUSY errorMessage="EBUSY: resource busy or locked, rmdir '%CODEX_HOME%\\.tmp\\bundled-marketplaces\\openai-bundled\\plugins\\chrome\\extension-host\\windows\\x64'"
bundled_plugins_reconcile_completed hasExternalPluginStateSync=true reason=startup

The lock owner was confirmed as extension-host.exe, launched by Edge's Codex extension. Edge remained active in the background even when no visible browser window was open.

Isolation result

With all Chromium processes and extension-host.exe stopped, restoring the marketplace made Browser and Computer Use remain visible through reconciliation. Reopening Edge allowed the native host to start and the failure recurred on a subsequent Codex reconciliation/restart.

Manually redirecting chrome\latest to the stable versioned cache temporarily avoided the lock, but Codex recreated the junction back to the active marketplace on startup, so this is not a durable workaround.

This suggests the current implementation exposes the staging/active marketplace directory as the native host runtime path, then attempts to atomically replace that same directory while Windows has the executable mapped. The failure path leaves the marketplace partially materialized instead of retaining or rolling back to the previous valid snapshot.

Potential fixes appear to be:

  • run the native host from an immutable versioned cache outside the replaceable marketplace tree;
  • stop/restart the native host before marketplace replacement;
  • retry/rollback cleanly on Windows file-lock errors; or
  • never publish latest to a directory that reconciliation later removes.
johnsilvavlogs · 2 months ago

Additional Windows reproduction from a current build, with a narrower config-drift variant that looks like the same failure class.

Environment

  • Date checked: 2026-06-23
  • OS: Windows 11 Pro, 10.0.26200
  • Codex Desktop package: OpenAI.Codex_26.616.9593.0_x64__2p2nqsd0c76g0
  • Codex CLI used for diagnosis: 0.142.0
  • Bundled Browser/Chrome/Computer Use plugin version in user cache: 26.616.71553
  • CUA runtime manifest: cua-node-0.0.2-20260620010411-120c650ffb83-windows-x64.zip

Symptom

Settings > Computer use showed:

Computer Use plugins unavailable

Key finding

This was not a missing Computer Use helper/runtime. The bundled plugin files were present, and the supported computer-use-client.mjs bootstrap could reach the helper and list apps.

Read-only runtime check before repair:

setupComputerUseRuntime(...) succeeded
sky.list_apps() returned 40 apps
codex-computer-use.exe was running from the Windows cua_node runtime

The broken layer was plugin/settings discovery from persisted config:

[marketplaces.openai-bundled]
source = "/Users/<mac-user>/.codex/.tmp/bundled-marketplaces/openai-bundled"

[mcp_servers.node_repl]
command = "/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl"

[mcp_servers.node_repl.env]
NODE_REPL_NODE_MODULE_DIRS = "/Applications/Codex.app/Contents/Resources/cua_node/lib/node_modules"
NODE_REPL_NODE_PATH = "/Applications/Codex.app/Contents/Resources/cua_node/bin/node"
NODE_REPL_TRUSTED_CODE_PATHS = "/Users/<mac-user>/.codex"
CODEX_HOME = "/Users/<mac-user>/.codex"
CODEX_CLI_PATH = "/Applications/Codex.app/Contents/Resources/codex"

On this Windows host, those macOS absolute paths made the configured surfaces inconsistent:

codex plugin marketplace list
# openai-bundled was absent

codex plugin list
# browser@openai-bundled, chrome@openai-bundled, computer-use@openai-bundled were absent

codex doctor
# node_repl stdio command "/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl" is not resolvable (os error 3)

The current user-level bundled marketplace did exist locally at:

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

and contained browser, chrome, computer-use, and latex plugin entries.

Local repair that restored discovery

I updated only the stale host-specific paths in config.toml:

[mcp_servers.node_repl]
command = '%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_repl.exe'

[mcp_servers.node_repl.env]
NODE_REPL_NODE_MODULE_DIRS = '%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_modules'
NODE_REPL_NODE_PATH = '%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node.exe'
NODE_REPL_TRUSTED_CODE_PATHS = '%USERPROFILE%\.codex'
CODEX_HOME = '%USERPROFILE%\.codex'
CODEX_CLI_PATH = '%USERPROFILE%\.codex\plugins\.plugin-appserver\codex.exe'

[marketplaces.openai-bundled]
source = '%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled'

After repair:

codex mcp list
# node_repl resolves to the Windows cua_node node_repl.exe

codex plugin marketplace list
# openai-bundled is present again

codex plugin list
browser@openai-bundled       installed, enabled  26.616.71553
chrome@openai-bundled        installed, enabled  26.616.71553
computer-use@openai-bundled  installed, enabled  26.616.71553

codex doctor
# config parse ok
# mcp: 2 server (1 stdio, 1 streamable_http), 0 disabled
# no node_repl unresolved-path warning

setupComputerUseRuntime(...) + sky.list_apps()
# still succeeds; returned 40 apps

Why this matters

This looks like the same broad class as the partial/stale bundled marketplace reports, but with a slightly different persistence bug: a Windows Codex install can retain macOS absolute paths in config.toml, so the runtime can be healthy while Settings/CLI plugin discovery concludes that Computer Use is unavailable.

Suggested product guard:

  1. On Desktop startup/reconcile, validate host-specific absolute paths for openai-bundled and node_repl against the current OS.
  2. If a configured bundled marketplace path is impossible for the current OS, recover from the local app/user bundled marketplace instead of letting settings render the generic unavailable state.
  3. Make Settings distinguish “plugin not available by policy/region” from “plugin discovery failed because configured marketplace/node_repl path is invalid.”
  4. Add Doctor/plugin diagnostics that explicitly verify computer-use@openai-bundled is discoverable from the active marketplace and that node_repl resolves to the current platform runtime.
zemeng5208 · 16 days ago

Disclosure: I maintain WinBridge Recovery, an independent Windows Codex Desktop recovery utility.

This is almost a direct match for the tool’s bundled-marketplace recovery path: the active .codex\.tmp\bundled-marketplaces\openai-bundled directory is partial, marketplace.json is missing, while versioned plugin caches still exist and later reads treat the marketplace as empty.

WinBridge Recovery resolves the currently installed official Codex package, validates the generated bundled marketplace and installed plugin/cache state, creates a rollback backup, and can rebuild the user-side marketplace/cache/pointer state when the active copy is incomplete or stale. It also checks related Chrome/native-host state because a locked extension host can be the event that leaves the marketplace half-written.

It does not modify WindowsApps or bypass product availability gates. So if the marketplace is intentionally reduced by a server-side feature decision, that is outside scope. But for the interrupted/partial local marketplace state described here, this is one of the clearest cases where the utility is intended to help.

MickeyWzt · 13 days ago

Fresh evidence from Store build 26.810.7004.0 shows the partial/stale marketplace class still reproducing, alongside the same-name source conflict.

  • The installed package marketplace declared seven descriptors: sites, browser, chrome, computer-use, latex, deep-research, and visualize.
  • The new Desktop startup/focus log materialized only six names in its generated runtime marketplace: sites, browser, chrome, computer-use, latex, and visualize.
  • The packaged Chrome plugin version was 26.810.52044, while local chrome\latest still targeted 26.810.50856.
  • Read-only strict validation failed because the expected current-version cache path chrome\26.810.52044\scripts\extension-ids.json did not exist.
  • Reconcile then failed repeatedly because .codex\.tmp\bundled-marketplaces\openai-bundled conflicted with a persisted stable source of the same marketplace name.

The package itself was healthy, Store-signed, and physically installed on the system AppX volume. This occurrence is therefore separate from the earlier cross-volume protected-file copy trigger.

Full sanitized postmortem:

https://gist.github.com/MickeyWzt/416bd69fa28b59c65aaec37aed9b34d1