Release tooling never bumps the plugin manifests — Claude Code plugin frozen at 0.1.0

[Konadu-Akwasi-Akuoko]

Problem

The Claude Code, Codex, and Cursor plugin manifests have never been
version-bumped. They were created at 0.1.0 and remain there, while the npm
packages have shipped 154 releases through v0.6.38 (latest, 2026-05-23):

Manifest	version
.claude-plugin/plugin.json	0.1.0
.claude-plugin/marketplace.json	0.1.0
.codex-plugin/plugin.json	0.1.0
.cursor-plugin/plugin.json	0.1.0

Confirmed impact — Claude Code

Claude Code gates plugin updates on the version field in plugin.json. Per the
plugins reference → Version management:

If you set version in plugin.json, you must bump it every time you want
users to receive changes. Pushing new commits alone is not enough, because
Claude Code sees the same version string and keeps the cached copy.

So anyone who installed the Claude Code plugin runs /plugin update and gets:

hyperframes is already at the latest version (0.1.0).

…and never receives any plugin content shipped since the initial commit.
Concrete example: commit 8662598 ("docs: add runtime adapter skills",
2026-04-30) added the runtime adapter skills and updated the manifest
description, but left version at 0.1.0 — so no existing Claude Code plugin
user ever received those skills via update.

Codex / Cursor — stale too, impact platform-dependent

The Codex and Cursor manifests are stale at 0.1.0 as well, though their update
models differ from Claude Code's:

• Cursor pins installs to the git commit SHA and auto-refreshes, and its
  version field is optional — so Cursor likely already tracks new commits
  regardless of the stale version. The 0.1.0 is mainly cosmetic there.
• Codex requires version in the manifest, and its update delivery for
  git-hosted plugins is under-documented — so whether the stale version blocks
  updates is unconfirmed.

Either way the manifests should track the release line for consistency, and the
Claude Code plugin is definitively broken today.

Root cause

scripts/set-version.ts hardcodes the set of paths it bumps:

const PACKAGES = [
  "packages/core", "packages/engine", "packages/player",
  "packages/producer", "packages/shader-transitions",
  "packages/studio", "packages/cli", "packages/aws-lambda",
];

It bumps those 8 npm package.json files, commits chore: release v<version>,
and tags — but never touches the plugin manifests. The entire version flow is
downstream of this array: set-version.ts → git tag → publish.yml (which
derives the release version from the tag name and calls gh release create).
CONTRIBUTING.md states the project uses fixed versioning ("every release bumps
all packages to the same version"); the plugin manifests appear to have been
omitted from that list by oversight rather than intent.

Proposed solution (Option A — keep fixed versioning) — recommended

Extend set-version.ts to also bump the three plugin plugin.json manifests so
they stay in lockstep with the npm packages:

• .claude-plugin/plugin.json, .codex-plugin/plugin.json,
  .cursor-plugin/plugin.json → top-level version

All three use a top-level version (same shape as package.json), so the
existing read/bump/write logic reuses directly. This is the only fix that works
uniformly across all three platforms: Claude Code gates on version, Codex
requires version, and Cursor accepts it harmlessly.

.claude-plugin/marketplace.json does not need bumping: per Claude Code's
resolution order, plugin.json's version (priority 1) overrides the marketplace
entry's version (priority 2), so the marketplace value is never consulted while
plugin.json carries one. Its version is redundant and could optionally be
dropped for hygiene.

The next release would carry the manifests to the current line (e.g. 0.6.39);
existing Claude Code plugin users would finally see a newer version on
/plugin update and pull all accumulated changes.

Alternative considered (Option B — drop version, use commit-SHA) — not portable

Removing the version field so Claude Code falls back to the git commit SHA
(auto-updating on every commit — the docs' fast-iteration path) works for Claude
Code, and matches how Cursor already operates (Cursor pins to the commit SHA;
version is optional there). However, Codex requires version in its
manifest, so dropping it would make the Codex manifest non-conformant. Option B
therefore can't be applied uniformly, which is why Option A is preferred.

Additional context

• No version bump appears in the git history of any of the four manifests since
  creation.
• Happy to send a PR for whichever option you prefer.

[miguel-heygen]

I'd be happy to review the pr! feel free to send it