Git marketplace auto-upgrade loops for annotated tag refs

Open 💬 1 comment Opened Jul 19, 2026 by 100yenadmin

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

  1. Create an annotated tag for a valid Codex plugin marketplace.
  2. Add the Git marketplace with codex plugin marketplace add owner/repo --ref <annotated-tag>.
  3. Upgrade or start Codex so the marketplace is activated.
  4. Repeat the upgrade/startup path.
  5. 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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗