›_ Codex Issues
Codex Issues / #28277

Windows Desktop: openai-bundled marketplace cache rebuilds incompletely, hiding Browser and Computer Use plugins

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

Summary

On Windows Codex Desktop, the temporary openai-bundled marketplace cache can rebuild incompletely and expose only the chrome plugin. When this happens, browser@openai-bundled and computer-use@openai-bundled are still enabled and present in the real plugin cache, but disappear from the plugin page / tool availability because the marketplace source only indexes chrome.

This has happened repeatedly on the same Windows machine, at least twice in two days: June 13, 2026 and June 15, 2026.

Environment

  • OS: Windows
  • Codex App package version: 26.609.4994.0
  • openai-bundled marketplace source from config: %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled
  • Enabled plugins in config:
  • computer-use@openai-bundled
  • chrome@openai-bundled
  • browser@openai-bundled
  • Real cache currently contains:
  • %USERPROFILE%\.codex\plugins\cache\openai-bundled\browser\26.609.41114
  • %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\26.608.12217
  • %USERPROFILE%\.codex\plugins\cache\openai-bundled\computer-use\26.609.41114

Observed state during failure

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins contains only:

chrome

Meanwhile %USERPROFILE%\.codex\plugins\cache\openai-bundled contains:

browser
chrome
computer-use

computer-use@openai-bundled, chrome@openai-bundled, and browser@openai-bundled remain enabled = true in config.toml.

Expected behavior

If the real bundled plugin cache contains browser, chrome, and computer-use, and all three are enabled, the temporary marketplace cache should expose all three plugins after rebuild.

Actual behavior

The temporary marketplace cache exposes only chrome. Browser and Computer Use disappear from the plugin page / available tools even though their real cache directories still exist and the plugins are enabled.

Workaround that restores visibility

  1. Stop any residual extension-host.exe helper if it is holding files under openai-bundled\plugins\chrome\extension-host\windows\x64.
  2. Rename, rather than delete, %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled to a timestamped backup.
  3. Fully restart Codex Desktop so it regenerates the temporary openai-bundled marketplace.
  4. Reopen or refresh plugin visibility.

This workaround restored visibility previously, but the failure recurred.

Additional note

This appears separate from the Computer Use startup/runtime error involving Package subpath './dist/.../computer_use_client_base.js' is not defined by "exports". The issue here is plugin visibility / marketplace indexing before any Computer Use startup attempt.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #26692
  • #26792
  • #26785
  • #27234
  • #28275

Powered by Codex Action

qinXpeng · 2 months ago

Reproduced again on a newer Windows build, confirming this issue is still present.

Environment

  • Windows 11 Pro, build 26200
  • Codex app package: 26.623.5175.0
  • Codex desktop/app-server build reported in logs: 26.623.41415
  • Observed: 2026-06-27, Asia/Shanghai

Symptom

Settings > Computer Use displayed:

Computer Use plugins unavailable

Restarting Codex multiple times did not recover the plugins.

Diagnostics

Computer Use itself was still installed and enabled, and a lightweight runtime check could connect to the Windows helper and enumerate installed applications. The failure was limited to plugin/marketplace discovery.

The active bundled marketplace directory contained only:

~/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/chrome

These expected entries were missing:

~/.codex/.tmp/bundled-marketplaces/openai-bundled/.agents/plugins/marketplace.json
~/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/computer-use

Meanwhile, the current Codex installation directory contained the complete openai-bundled marketplace, and the installed Computer Use plugin cache was intact.

The log contained the corresponding warning:

configured non-curated plugin no longer exists in discovered marketplaces during cache refresh plugin="computer-use" marketplace="openai-bundled"

The incomplete marketplace directory timestamp did not change across application restarts, confirming that a normal restart does not validate or regenerate the persistent broken state.

Recovery

Deleting ~/.codex/.tmp completely and restarting Codex regenerated the bundled marketplace. Computer Use and the other bundled plugins immediately reappeared.

This suggests startup should validate that the bundled marketplace manifest and configured bundled plugins exist, then rebuild the marketplace atomically when the active directory is incomplete.

lightworker4love · 1 month ago

Cross-platform occurrence: macOS Desktop 26.715.31925

Confirming the same failure class described in this issue also occurs on macOS, not just Windows.

Environment:

  • macOS, Mac mini M2 Pro, 16GB RAM
  • Codex Desktop 26.715.31925 (build 5551)
  • Bundled CLI 0.145.0-alpha.18, PATH CLI 0.144.6

Symptom:
Bundled app-server repeatedly triggers plugin marketplace refresh/auto-upgrade cycles. Each cycle materializes openai-bundled into a new UUID-named staging directory under ~/.codex/.tmp/bundled-marketplaces/, but activation/cleanup never completes, leaving an incomplete copy behind.

  • Staging copies contain only 4-5 plugins / 975-1,238 entries
  • Production openai-bundled directory correctly has 7 plugins / 1,485 entries, verified unchanged throughout
  • Prior to detection, this accumulated to 229 staging directories totaling ~21.3 GiB over approximately 6 days (2026-07-13 to 2026-07-19)

After manual cleanup, recurrence confirmed via read-only monitoring:

  • 2 burst events observed within 25 minutes (13:34 and 13:59 CST)
  • Total staging size grew from 779,756 KB to 1,599,756 KB (+105%) in that window
  • No single Codex process showed sustained CPU >90%; this is a storage accumulation issue, not a performance/hang issue

Notes:

  • No internal error code available — unified log has no marketplace messages; local logs_2.sqlite blocked by existing write trigger (0 rows)
  • No independent launchd marketplace timer found; trigger originates inside the Codex bundled app-server itself
  • Happy to share the full evidence log (per-directory UUID, timestamp, size table) if useful for triage

Filing here rather than opening a new issue since the failure signature matches closely (incomplete marketplace rebuild, subset of plugins exposed). Let me know if a separate macOS-specific issue would be preferred instead.

zemeng5208 · 16 days ago

I maintain WinBridge Recovery for Windows Codex Desktop bundled-plugin state recovery: https://github.com/zemeng5208/winbridge-recovery

The newer 26.623 reproduction in this thread is a very direct match for the failure class WinBridge targets: the installed package and Computer Use runtime/cache are healthy, but the active openai-bundled marketplace is stuck in a partial state containing only Chrome and missing .agents/plugins/marketplace.json / computer-use. A normal restart then keeps reusing the broken state instead of validating it.

WinBridge v3.1.1 treats the installed AppX resources, active bundled marketplace, versioned plugin cache/latest, and runtime/helper state as separate consistency layers. For this state it can validate the current official package as the source, stage a complete user-owned marketplace, verify the required manifests/files and hashes, keep rollback data, and switch only after validation succeeds.

That is intentionally more conservative than blindly deleting all of .codex/.tmp: if the active marketplace is healthy, repair is skipped; if staging is incomplete, the previous usable state is retained. It also does not modify WindowsApps ownership/ACLs or bypass account/feature gates.

If marketplace/cache/runtime are already complete and the only remaining failure is an upstream Computer Use bridge/runtime bug, WinBridge stops at diagnosis rather than claiming to repair that layer.