›_ Codex Issues
Codex Issues / #24390

Codex Windows Desktop: Agent uses stale plugin cache path after plugin update, and session execution details are lost after restart

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

What version of the Codex App are you using (From “About Codex” dialog)?

26.521.10419

What subscription do you have?

business

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

I am seeing two issues in Codex Windows Desktop related to plugin usage and session diagnostics.

First, after the openai-curated/superpowers plugin was updated, the Agent appeared to use a stale plugin cache path instead of the current plugin path.

In my current Codex workspace, the visible plugin path is:

.codex/plugins/cache/openai-curated/superpowers/6188456f/skills/using-superpowers/SKILL.md

6188456f appears to be the current plugin cache hash on my machine. This path was created/updated around May 23.

However, when I used @superpower in a project conversation, the Agent reported that the superpower plugin was unavailable. When I inspected the plugin path details at that time, the Agent appeared to reference a different cache hash instead of 6188456f.

This suggests that after the plugin update, Codex may not have injected the latest valid plugin path into the Agent environment.

Second, after restarting Codex / reopening the same conversation, the previously visible command/thinking details were no longer available. Only file-edit records and browser-call records remained visible. Because of this, I could no longer recover the exact stale path that the Agent had referenced.

What steps can reproduce the bug?

  1. Open a project workspace in Codex Windows Desktop.
  2. Make sure the openai-curated/superpowers plugin exists in the local Codex plugin cache.
  3. Confirm the current visible plugin path. In my case it was:

.codex/plugins/cache/openai-curated/superpowers/6188456f/skills/using-superpowers/SKILL.md

  1. In an existing or active project conversation, ask the Agent to use @superpower to continue project work.
  2. Observe that the Agent reports the superpower plugin as unavailable.
  3. Inspect the Agent's plugin path / environment details.
  4. Compare the path used by the Agent with the current plugin path in the Codex workspace.
  5. Keep Codex open and observe that more command/thinking details are visible at this point.
  6. Restart Codex Desktop or reopen the same conversation later.
  7. Try to inspect the same command/thinking details again.
  8. Observe that the previous diagnostic details are no longer visible, and only file-edit records and browser-call records remain.

What is the expected behavior?

After a plugin update, Codex should ensure that the Agent receives the current valid plugin cache path.

Expected behavior for plugin loading:

  • The Agent should use the latest valid plugin cache path automatically.
  • Existing conversations should refresh plugin path injection after the plugin is updated, or Codex should clearly indicate that the conversation/session needs to be restarted.
  • The Agent should not silently use or reference a stale plugin cache path that causes the plugin to be reported as unavailable.
  • If a plugin cache hash changes, Codex should detect stale paths and re-resolve to the latest valid path.

Expected behavior for session diagnostics:

  • After restarting Codex or reopening a conversation, enough diagnostic information should remain available for debugging and bug reporting.
  • At minimum, Codex should preserve command execution records, command outputs or summaries, tool calls, plugin paths used by the Agent, and relevant environment/path details.
  • If full thinking details are intentionally not persisted, command/tool execution details should still remain available.

Additional information

Environment:

  • Product: Codex Windows Desktop
  • OS: Windows
  • Codex Desktop version: <fill in version>
  • Workspace type: Project workspace
  • Plugin involved: openai-curated/superpowers

Current visible plugin path:

.codex/plugins/cache/openai-curated/superpowers/6188456f/skills/using-superpowers/SKILL.md

Observed behavior:

  • The Agent reported that the superpower plugin was unavailable.
  • The Agent appeared to reference a plugin cache path whose hash did not match 6188456f.
  • After restarting/reopening Codex, the detailed command/thinking records that showed this path were no longer visible.
  • Only file edit records and browser call records remained visible.

Impact:

  • The Agent may fail to use an installed/updated plugin because it references an outdated plugin cache path.
  • Users cannot easily confirm which plugin version/path the Agent is actually using.
  • After restarting Codex or reopening a conversation, diagnostic details may disappear.
  • Users lose the evidence needed to file a precise bug report.
  • This makes plugin-related failures hard to reproduce, verify, and report.

Questions:

  1. Does Codex Windows Desktop refresh plugin path injection after a plugin cache update?
  2. Can existing conversations retain stale plugin cache paths after a plugin update?
  3. Is it expected that @superpower can become unavailable if the Agent has an outdated plugin cache path?
  4. Are command execution details and tool-call details expected to persist after reopening a conversation?
  5. If full thinking details are not persisted by design, could Codex still preserve the command/tool execution history needed for debugging?

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 1 month ago

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

  • #24189
  • #24287
  • #23903

Powered by Codex Action

clairernovotny · 1 month ago

I hit what looks like the same stale plugin-cache-path failure on macOS in Codex Desktop, and traced a concrete cache-invalidation path in current main (96f1347fa3504dca512ef11aa97027a5dfcbfc56).

Observed local state:

  • The injected skills_instructions developer metadata for an active session contained roots like:
  • /Users/claire/.codex/plugins/cache/openai-curated/github/be69e54e/skills
  • /Users/claire/.codex/plugins/cache/openai-curated/superpowers/be69e54e/skills
  • The actual plugin cache on disk had already advanced to acdd3141, and the old be69e54e directories no longer existed.
  • That made the model-visible skill paths stale even though the current plugin cache existed and the skills were available on disk under the newer cache version.

Code path I found:

  1. Per turn, Codex loads plugin roots and then skills:
  • codex-rs/core/src/session/turn_context.rs
  • plugins_manager.plugins_for_config(...)
  • plugin_outcome.effective_plugin_skill_roots()
  • skills_manager.skills_for_config(...)
  1. The skills prompt is rendered from that outcome:
  • codex-rs/core/src/session/mod.rs
  • build_available_skills(...)
  • AvailableSkillsInstructions::from(...)
  1. core-skills/src/render.rs renders concrete plugin-cache paths into the prompt. It recognizes paths under plugins/cache/... and aliases roots like:
  • /Users/.../.codex/plugins/cache/openai-curated/<plugin>/<cache-version>/skills
  1. Curated plugin refresh installs the new short-SHA cache version and removes older cache dirs:
  • core-plugins/src/loader.rs::refresh_curated_plugin_cache
  • core-plugins/src/store.rs::install_with_version
  • core-plugins/src/store.rs::remove_old_plugin_versions
  1. PluginsManager::plugins_for_config caches PluginLoadOutcome by config TOML version only:
  • core-plugins/src/manager.rs
  • let config_version = version_for_toml(&config.config_layer_stack.effective_config())

The cache key does not include the active plugin cache version/path, so the cached PluginLoadOutcome can preserve old effective_plugin_skill_roots after the filesystem cache advances.

  1. The curated background sync path clears only PluginsManager cache when it refreshes the curated plugin cache:
  • core-plugins/src/manager.rs::start_curated_repo_sync
  • on cache_refreshed, it calls manager.clear_cache()

Other app-server paths do clear both plugin and skill caches via spawn_effective_plugins_changed_task, but this curated sync path does not appear to invoke that callback or clear SkillsManager.

So this seems broader than Windows: Windows may have an additional SkillsWatcher/rename failure mode, but stale injected paths can also happen when a curated plugin cache update succeeds and removes the old versioned cache dir while model-visible skill metadata or skill/plugin load outcomes still reference the old concrete path.

Possible fixes:

  • When curated plugin cache refreshes, also clear SkillsManager or route through the existing on_effective_plugins_changed callback that clears both caches.
  • Include active plugin cache version/path state in the plugin/skill cache key, not only the effective config TOML version.
  • Before rendering skills_instructions, validate that plugin skill roots still exist; if they do not, force reload plugin and skill outcomes rather than emitting dead cache paths.
  • Longer term, avoid making ephemeral versioned cache directories the model-visible contract; render stable plugin identities or stable active-version paths instead.
lengmingz · 1 month ago

I found this issue via the duplicate pointer from #25285. The cache-invalidation analysis here matches the failure I reproduced on Windows, so I updated the proposed fix branch to cover both the stale-path compatibility issue and the stale PluginLoadOutcome cache issue described above.

What the branch now does:

  • Retains superseded plugin cache version directories so already-injected absolute skill paths remain readable after a plugin cache update.
  • Adds a per-plugin .active-version marker so retaining old directories does not make active-version selection ambiguous.
  • Includes active plugin cache versions in PluginsManager's cached PluginLoadOutcome key, so the manager will not keep returning old effective_plugin_skill_roots when the active plugin cache version changes under the same config.
  • Routes curated startup cache refreshes through the existing effective-plugins-changed callback so app-server clears both plugin and skill caches.

Local verification on Windows:

  • just fmt
  • just test -p codex-core-plugins (191 passed; bench smoke compiled and started)
  • just fix -p codex-core-plugins (passed; reported an existing manifest.rs large_enum_variant warning)

I tried to open an upstream PR from the fork branch, but GitHub rejects the create-PR API call for this account/session with CreatePullRequest permission errors. The compare link is ready for maintainer review/cherry-pick.

lengmingz · 1 month ago

Additional handoff artifact for the proposed fix branch: I opened a fork-local mirror PR because GitHub still rejects creating the upstream PR from this account/session.

The mirror PR is draft and only intended as a stable PR-style review/handoff page for the upstream fix.

lengmingz · 1 month ago

Update: the fork-local mirror PR is now marked ready for review (no longer draft):

It still targets the same verified commit: 6c2c94daf4026f526465cc4d974348091fb45488.

lengmingz · 1 month ago

Maintenance update: rebased the handoff branch onto current openai/codex@main after #25318 landed.

Fresh verification after rebase:

  • just fmt
  • just test -p codex-core-plugins (191 passed; bench smoke compiled and started)
  • just fix -p codex-core-plugins (passed; existing manifest.rs large_enum_variant warning only)
lengmingz · 1 month ago

Maintenance update: rebased the handoff branch onto current openai/codex@main (3b7334d099b339e7b18418a0cf7ac34e7bed2e43).

Fresh Windows verification after rebase:

  • just fmt
  • just test -p codex-core-plugins (191 passed; bench smoke compiled and started)
  • just fix -p codex-core-plugins (passed; existing core-plugins/src/manifest.rs large_enum_variant warning only)

I retried creating the upstream PR, but GitHub still rejects this account/session with CreatePullRequest permission errors.

lengmingz · 1 month ago

Maintenance update: rebased the handoff branch onto current openai/codex@main (9756316d89968945212cd5f958b2b972c77c9e09) after upstream touched core-plugins/src/manager_tests.rs.

Fresh Windows verification after rebase:

  • just fmt
  • just test -p codex-core-plugins (192 passed; bench smoke compiled and started)
  • just fix -p codex-core-plugins (passed; existing core-plugins/src/manifest.rs large_enum_variant warning only)

I retried creating the upstream PR, but GitHub still rejects this account/session with CreatePullRequest permission errors.