›_ Codex Issues
Codex Issues / #32636

Desktop plugin replacement can leave stale skill paths and MCP tool inventory until restart

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

While Codex Desktop remained running, I replaced a local-marketplace plugin using the Codex CLI. A resumed task continued to advertise a removed SKILL.md path and exposed no MCP tools from that plugin. A genuinely new task in the same running app also advertised the removed path while its MCP tools were present, showing that skill metadata and MCP registration can refresh independently. Restarting Codex and creating another task restored a coherent current surface.

Environment: macOS, Codex Desktop 0.144.0-alpha.4, Visible Browser Lab upgraded from 0.4.7 to 0.4.8.

Expected: after successful plugin replacement, newly created tasks advertise the installed version’s skill paths and expose its MCP tools. Existing tasks should either remain explicitly pinned or report that restart is required.

Actual: tasks can retain paths to removed cache directories, and skill/tool surfaces can disagree.

Source analysis found that the resolved plugin outcome cache was keyed by configuration and rules but not the active installed artifact. A validated candidate fix writes a store-owned generation on every atomic plugin activation, includes (active root, generation) in the plugin cache key, and includes the corresponding per-load snapshot generation in the skills cache key. A same-version external-replacement regression proves skill content and MCP configuration advance together. Existing tasks retain their established context; newly created tasks resolve replacements coherently.

Workaround: create a genuinely new task after replacement. If it remains stale or lacks tools, restart Codex and create another new task.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #31383

Powered by Codex Action

wycats · 1 month ago

This definitely overlaps with #31383, but I don't think it's exactly the same thing.

In #31383, a running session already has hook commands pointing into the plugin cache, and an automatic marketplace update replaces the path underneath it. The next session works because it resolves the new path.

What I hit here is the other side of that lifecycle: after a successful external replacement, a brand new task in the still-running Desktop app can still resolve the old skill path, and the skill and MCP surfaces can disagree about which plugin is active. Restarting the app clears it.

The fix I prototyped for this issue puts the active plugin root and install generation into the plugin cache key, and carries that generation into the skills cache. That gets new tasks onto one coherent version of the plugin, but it doesn't solve the #31383 problem where an already-running task has a path removed out from under it.

So I think they're related enough that we should keep them linked, but closing this as a dupe would lose one of the two cache-lifecycle problems.

wycats · 1 month ago

I pushed the candidate fix to wycats/plugin-replacement-refresh, kept it up to date with current main, and reran the relevant tests (316 plugin tests and 120 skills tests). Everything is green, including fmt.

The regression test reproduces the same-version replacement case directly: replace the plugin outside the running app, then verify that a new task gets both the new skill and the new MCP config. The current commit is eefa7a19ba.

Happy to open a PR if invited.

bkstream70 · 1 month ago

I hit what looks like the same stale skill-path lifecycle today on macOS with codex-cli 0.144.6 and a local marketplace plugin.

Observed sequence:

  1. A new Codex session injected the oxi-task-runner skill with a file path under:

~/.codex/plugins/cache/oxi-skills/oxi-task-runner/4.3.577/skills/oxi-task-runner/SKILL.md

  1. Following the injected skill path failed immediately:

No such file or directory

  1. The installed plugin cache only had the next version:

~/.codex/plugins/cache/oxi-skills/oxi-task-runner/4.3.578/...

  1. Searching for the old path found it only in session logs, not as a live cache directory. Discovering the newest installed SKILL.md manually worked.

Why this matters for skills specifically: current skill instructions tell agents to open the exact advertised SKILL.md before task actions. If the advertised path points to a removed cache directory, strict skill-following breaks and the agent has to invent a fallback resolver.

This also matches the documented cache shape from the Codex manual: installed plugins are loaded from ~/.codex/plugins/cache/$MARKETPLACE_NAME/$PLUGIN_NAME/$VERSION/, but I do not see a documented retention guarantee for superseded versions.

Expected behavior: newly created sessions should not advertise removed SKILL.md paths. Either the skill metadata cache should be invalidated with plugin activation, or superseded cache directories should be retained while sessions can still reference them, or the runtime should surface a clear restart/refresh requirement.

Local tracking issue with the exact evidence from my run: https://github.com/OXI-717/oxi-skills/issues/1048