codex - 💡(How to fix) Fix Plugin cache refresh can keep stale bundled/local plugin contents when source changes without a version bump [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#21138Fetched 2026-05-06 06:26:07
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Participants
Timeline (top)
labeled ×3

Root Cause

The installed app bundle had newer Browser Use plugin files, including scripts/browser-client.mjs, but Codex continued to load the older cached copy because the plugin manifest still reported:

Code Example

~/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha1/

---

"version": "0.1.0-alpha1"

---

~/.codex/plugins/cache/<marketplace>/<plugin>/<version>/

---

~/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha1/
RAW_BUFFERClick to expand / collapse

What version of the Codex App are you using?

Observed with Codex Desktop for Windows app package OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0.

What platform is your computer?

Windows.

What issue are you seeing?

Codex can continue loading stale plugin contents from ~/.codex/plugins/cache after the underlying bundled/local marketplace plugin source has changed, if the plugin manifest version string did not change.

I observed this with the bundled Browser Use plugin:

~/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha1/

The installed app bundle had newer Browser Use plugin files, including scripts/browser-client.mjs, but Codex continued to load the older cached copy because the plugin manifest still reported:

"version": "0.1.0-alpha1"

Manually comparing the app-bundled Browser Use source against the active cache showed stale cached runtime content. Syncing the cache from the current source fixed the Browser Use behavior locally, which points at cache invalidation rather than the local device as the underlying failure mode.

This is dangerous for bundled/alpha plugin assets because a plugin can receive behavior fixes without a manifest version bump, while Codex treats the existing cache directory as fresh solely because the version directory already exists.

What steps can reproduce the bug?

A minimal reproduction should be possible with any local/non-curated marketplace plugin:

  1. Install or enable a local marketplace plugin with a manifest version, for example 0.1.0-alpha1.
  2. Let Codex install it into the persistent cache under:
~/.codex/plugins/cache/<marketplace>/<plugin>/<version>/
  1. Change the source plugin contents while keeping .codex-plugin/plugin.json at the same version value.
  2. Restart or continue Codex so plugin cache refresh runs.
  3. Observe that Codex keeps loading the old cache entry instead of reinstalling from the changed source.

For the observed Browser Use case, the source was the app-bundled openai-bundled/browser-use plugin and the stale active cache was:

~/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha1/

What is the expected behavior?

Plugin cache freshness should not be determined by plugin.json.version alone.

For local and bundled plugin sources, Codex should detect when source contents changed and reinstall/replace the cached plugin entry even if the manifest version string is unchanged.

A robust cache metadata record would likely include some combination of:

  • source content digest,
  • plugin manifest digest,
  • source path or source identity,
  • installed digest,
  • app build/version for bundled plugin sources,
  • marketplace revision where applicable.

If the source digest or bundle provenance changes, Codex should atomically replace the cached entry. If Codex intentionally relies on plugin authors bumping versions for every bundled asset change, that should be enforced in release tooling or surfaced clearly when source and cache diverge.

Additional information

I searched existing issues for related cache/plugin reports before filing. These are adjacent but appear distinct:

  • #19834 is about clearly identifying stale marketplace repository clones.
  • #17001 is about confusion between source and cache directories.
  • #18863 is about symlinks being dropped when copying plugin cache contents.

This issue is different: the source bundle/local marketplace can be current, but Codex still considers the persistent installed cache valid because the manifest version string is unchanged.

Relevant source-level behavior in the public repo:

  • codex-rs/core-plugins/src/store.rs

    • PluginStore::plugin_root() stores plugins under plugins/cache/<marketplace>/<plugin>/<version>.
    • PluginStore::active_plugin_version() discovers the active version from existing cache directory names.
    • install_with_version() can atomically replace the cache, but only when refresh decides to call it.
  • codex-rs/core-plugins/src/loader.rs

    • refresh_non_curated_plugin_cache_with_mode() reads plugin_version_for_source(source_path) from the manifest.
    • In IfVersionChanged mode it skips reinstall when store.active_plugin_version(&plugin_id) == Some(plugin_version).
    • load_plugin() then loads from store.active_plugin_root().

The problem is the missing content/provenance validation between “source plugin at this same version” and “installed cache entry for this version.”

extent analysis

TL;DR

To fix the issue, Codex should validate the freshness of plugin cache entries based on a combination of factors, including source content digest, plugin manifest digest, and source path, rather than relying solely on the plugin.json.version string.

Guidance

  • The issue arises from Codex's current behavior of treating the existing cache directory as fresh if the version directory already exists, even if the underlying plugin source has changed.
  • To mitigate this, the refresh_non_curated_plugin_cache_with_mode function in loader.rs should be modified to check for changes in the source plugin contents, not just the version string.
  • A possible solution is to introduce a content digest or hash that is updated whenever the plugin source changes, and use this digest to determine cache freshness.
  • The install_with_version function in store.rs can be used to atomically replace the cache entry if the source contents have changed.

Example

No code example is provided as the issue requires changes to the Codex App's internal logic and caching mechanism.

Notes

The proposed solution requires modifications to the Codex App's source code, specifically in the codex-rs/core-plugins module. The changes should ensure that the cache freshness is determined by a combination of factors, including source content digest, plugin manifest digest, and source path.

Recommendation

Apply a workaround by modifying the refresh_non_curated_plugin_cache_with_mode function to check for changes in the source plugin contents, and use the install_with_version function to atomically replace the cache entry if necessary. This will ensure that the plugin cache is updated correctly even if the plugin.json.version string remains unchanged.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING