What version of Codex is affected?
The marketplace upgrade implementation on current main (0fb559f0f6) and Codex Desktop CLI 0.145.0-alpha.18.
What issue are you seeing?
A Git-backed marketplace configured with an annotated tag is treated as stale on every startup or marketplace refresh, even when the checked-out marketplace is already at that tag.
git_remote_revision runs git ls-remote <source> <tag> and records the first SHA, which is the annotated tag object. The clone/checkout path records git rev-parse HEAD, which is the peeled commit. Those SHAs can never match, so the no-op guard never succeeds.
With multiple app-server processes, this can create repeated full repository clones under marketplace staging and backup directories and eventually exhaust local disk space.
Steps to reproduce
- Create an annotated tag for a valid Codex plugin marketplace.
- Add the Git marketplace with
codex plugin marketplace add owner/repo --ref <annotated-tag>.
- Upgrade or start Codex so the marketplace is activated.
- Repeat the upgrade/startup path.
- Observe that the marketplace is cloned and activated again despite the tag being unchanged.
For an annotated tag, the relevant Git outputs have this shape:
<tag-object-sha> refs/tags/example
<commit-sha> refs/tags/example^{}
The installed metadata contains <commit-sha>, while the current remote lookup returns <tag-object-sha>.
Expected behavior
Marketplace remote revision resolution should prefer the peeled ^{} commit for annotated tags, while preserving the existing behavior for branches, lightweight tags, HEAD, and full commit SHA refs. Once installed metadata matches that commit, subsequent startup refreshes should be no-ops.
What version of Codex is affected?
The marketplace upgrade implementation on current
main(0fb559f0f6) and Codex Desktop CLI0.145.0-alpha.18.What issue are you seeing?
A Git-backed marketplace configured with an annotated tag is treated as stale on every startup or marketplace refresh, even when the checked-out marketplace is already at that tag.
git_remote_revisionrunsgit ls-remote <source> <tag>and records the first SHA, which is the annotated tag object. The clone/checkout path recordsgit rev-parse HEAD, which is the peeled commit. Those SHAs can never match, so the no-op guard never succeeds.With multiple app-server processes, this can create repeated full repository clones under marketplace staging and backup directories and eventually exhaust local disk space.
Steps to reproduce
codex plugin marketplace add owner/repo --ref <annotated-tag>.For an annotated tag, the relevant Git outputs have this shape:
The installed metadata contains
<commit-sha>, while the current remote lookup returns<tag-object-sha>.Expected behavior
Marketplace remote revision resolution should prefer the peeled
^{}commit for annotated tags, while preserving the existing behavior for branches, lightweight tags,HEAD, and full commit SHA refs. Once installed metadata matches that commit, subsequent startup refreshes should be no-ops.