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

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.