What issue are you seeing?
The root cause was a stale cloned copy of the marketplace repository on disk. The Codex app detected that stale marketplace state, but there was no obvious way for me to tell this apart from a stale installed plugin cache or a marketplace/plugin upgrade problem.
That made the failure mode confusing: the marketplace entry and upstream plugin release appeared current, while Codex still exposed an older plugin skill. From the user's point of view, it looked like Codex had a stale cached plugin version that could not be refreshed, when the actual problem was the stale marketplace repository clone that Codex was already able to detect.
Codex should make this state visible and actionable so users can distinguish:
- a stale marketplace repository checkout,
- a stale installed plugin cache entry,
- an enabled plugin resolving from an older installed version,
- and a marketplace that is genuinely already up to date.
What steps can reproduce the bug?
- Add or use a Git marketplace with an enabled plugin.
- Have the local cloned marketplace repository become stale relative to the expected marketplace state.
- Start or continue a Codex session that loads skills from that marketplace.
- Inspect the enabled plugin or referenced skill version.
Observed locally with codex-cli 0.123.0:
- The marketplace entry and upstream plugin release pointed to
superteam v1.2.0.
- Codex still exposed an installed skill from an older cache path:
~/.codex/plugins/cache/patinaproject-skills/superteam/1.0.0/skills/superteam/SKILL.md
- The available CLI output did not make it clear that the stale marketplace repository clone was the root cause.
- Because Codex had detected the stale repository state internally, the missing piece was discoverability and user-facing diagnostics, not merely plugin cache refresh behavior.
What is the expected behavior?
When Codex detects a stale marketplace repository clone, it should clearly surface that fact in the app and/or CLI output, with enough detail to distinguish it from stale plugin cache state.
Ideally, Codex should show:
- which marketplace repository clone is stale,
- what version/revision Codex expected,
- what local revision is currently present,
- which enabled plugins or skills are affected,
- and the recommended action to refresh or repair the marketplace checkout.
If the Plugin Directory or app already detects this condition, it should present a visible warning or repair action instead of leaving users to infer the issue from cache paths and marketplace metadata.
Additional information
The original report focused on the installed plugin cache because that was the most visible symptom: Codex was resolving a skill from an older cache directory while the marketplace metadata appeared to point at a newer plugin version.
After further investigation, the confirmed root cause was the stale marketplace repository clone. The issue is that there was no obvious user-facing signal to tell that this was the cause, even though the Codex app detected it.
Relevant public files from the original investigation:
What issue are you seeing?
The root cause was a stale cloned copy of the marketplace repository on disk. The Codex app detected that stale marketplace state, but there was no obvious way for me to tell this apart from a stale installed plugin cache or a marketplace/plugin upgrade problem.
That made the failure mode confusing: the marketplace entry and upstream plugin release appeared current, while Codex still exposed an older plugin skill. From the user's point of view, it looked like Codex had a stale cached plugin version that could not be refreshed, when the actual problem was the stale marketplace repository clone that Codex was already able to detect.
Codex should make this state visible and actionable so users can distinguish:
What steps can reproduce the bug?
Observed locally with
codex-cli 0.123.0:superteamv1.2.0.What is the expected behavior?
When Codex detects a stale marketplace repository clone, it should clearly surface that fact in the app and/or CLI output, with enough detail to distinguish it from stale plugin cache state.
Ideally, Codex should show:
If the Plugin Directory or app already detects this condition, it should present a visible warning or repair action instead of leaving users to infer the issue from cache paths and marketplace metadata.
Additional information
The original report focused on the installed plugin cache because that was the most visible symptom: Codex was resolving a skill from an older cache directory while the marketplace metadata appeared to point at a newer plugin version.
After further investigation, the confirmed root cause was the stale marketplace repository clone. The issue is that there was no obvious user-facing signal to tell that this was the cause, even though the Codex app detected it.
Relevant public files from the original investigation:
superteamv1.2.0release tag: https://github.com/patinaproject/superteam/tree/v1.2.0superteamCodex plugin manifest: https://github.com/patinaproject/superteam/blob/v1.2.0/.codex-plugin/plugin.jsonsuperteampackage metadata: https://github.com/patinaproject/superteam/blob/v1.2.0/package.jsonsuperteamskill file: https://github.com/patinaproject/superteam/blob/v1.2.0/skills/superteam/SKILL.md