gm-plugkit@2.0.2088 bootstrap fails: bundled plugkit.sha256 stale vs plugkit-bin v0.1.962 (breaks every fresh install)

[lkraider]

Summary

Every fresh install of gm-plugkit (confirmed at 2.0.2088, and reproduced identically on 2.0.2087/2.0.2086) fails bootstrap with a sha256 mismatch error when fetching plugkit.wasm. Root cause: the plugkit.sha256 manifest bundled inside the gm-plugkit npm package is stale relative to the currently-published plugkit-bin GitHub release (v0.1.962).

Repro

$ npx -y bun x gm-plugkit@latest spool
...
Bootstrap failed: sha256 mismatch for plugkit.wasm: expected 874f5a3524d8a080a2880567cc3808ae727f4c2b4f35ad6fc33e932fd6c4c567, got 12bf61f61d47fddffc6ad0d7d1ced8e6d2616959a2813547da00ee913abc50cd

Reproduces on a completely clean ~/Library/Caches/plugkit (no local caching issue) and across multiple gm-plugkit versions (2.0.2086, 2.0.2087, 2.0.2088 all bundle the identical stale hash).

Root cause

bootstrap.js (extractNpmPackageWithRetry / downloadFromGithubReleases, around line 401 and 500) compares the freshly-downloaded plugkit.wasm against expectedSha, which is read from a manifest bundled inside the gm-plugkit npm package itself (package/plugkit.sha256), not fetched live:

const expectedSha = shaManifest ? (shaManifest[remoteArtifact] || (useSlim ? null : shaManifest[wasmName])) : null;
...
if (got !== expectedSha) {
  throw new Error(`sha256 mismatch for ${wasmName}: expected ${expectedSha}, got ${got}`);
}

That bundled manifest currently contains:

{"plugkit.wasm":"874f5a3524d8a080a2880567cc3808ae727f4c2b4f35ad6fc33e932fd6c4c567"}

(confirmed identical across gm-plugkit@2.0.2086, 2.0.2087, 2.0.2088 npm tarballs)

But the live, currently-published plugkit-bin release v0.1.962 (both via the npm plugkit-wasm@0.1.962 package and the GitHub Releases asset) ships plugkit.wasm with sha256:

12bf61f61d47fddffc6ad0d7d1ced8e6d2616959a2813547da00ee913abc50cd

Confirmed directly against GitHub Releases (authenticated gh API, to rule out any local/CDN caching):

$ gh release download v0.1.962 -R AnEntrypoint/plugkit-bin -p "plugkit.wasm.sha256" -O -
12bf61f61d47fddffc6ad0d7d1ced8e6d2616959a2813547da00ee913abc50cd  plugkit.wasm

This exactly matches the "got" hash from the bootstrap failure — i.e. the download itself is correct and consistent; only the bundled expectation in gm-plugkit's npm package is out of date. It looks like plugkit-bin was tagged/released (v0.1.962) without gm-plugkit's bundled plugkit.sha256 manifest being regenerated/republished in lockstep.

Because the GitHub-releases fallback path (downloadFromGithubReleases) reuses the same stale expectedSha for its own post-download verification (it only self-verifies against a live-fetched .sha256 sidecar for its own gh-releases sha match, but the final check at the bootstrap level still re-checks against the bundled manifest), falling back to GitHub Releases does not route around the bug either.

Separate but related: unauthenticated GitHub API rate limiting

Independently, bootstrap.js (line ~757, checking AnEntrypoint/plugkit-bin releases, and the agentplug-runner install path checking AnEntrypoint/agentplug-bin's latest release) calls the GitHub REST API with no Authorization header and no use of GITHUB_TOKEN/GH_TOKEN from the environment:

$ curl https://api.github.com/repos/AnEntrypoint/agentplug-bin/releases/latest
{"message":"API rate limit exceeded for <ip>. ...","documentation_url":"..."}

Unauthenticated GitHub API requests are capped at 60/hour per IP, which is easy to exhaust (e.g. behind a shared/NAT'd IP, or simply from repeated bootstrap attempts while debugging). Using an available GITHUB_TOKEN/GH_TOKEN env var when present (authenticated requests get 5000/hour) would make bootstrap far more resilient, especially for anyone iterating on install issues like this one.

Impact

Every fresh install (bun x gm-plugkit@latest spool / npx -y gm-plugkit@latest spool) is currently broken for any project/machine without a pre-existing valid cache. This affects the gm skill's documented boot line directly. Additionally there's currently no documented way to pin/install a previous known-good gm-plugkit version to work around this — npx -y gm-plugkit@<version> spool works for selecting the wrapper version, but since the stale hash is bundled in every recent release (2086-2088 confirmed), there is no still-published version of gm-plugkit on npm that pairs correctly with the current plugkit-bin v0.1.962 without this fix.

Suggested fixes

• Republish gm-plugkit with an updated bundled plugkit.sha256 matching the current plugkit-bin release, and/or
• Add a CI check that fails the gm-plugkit release process if its bundled plugkit.sha256 doesn't match the plugkit-bin release it's meant to pair with, and/or
• Have bootstrap fetch the expected hash live from plugkit-bin's release .sha256 sidecar rather than trusting a manifest baked into gm-plugkit at publish time (this would make the two packages self-consistent even if release timing drifts), and/or
• Document (and ideally implement) a supported way to pin/rollback to a last-known-good gm-plugkit + plugkit-bin version pair for exactly this kind of skew.
• Use GITHUB_TOKEN/GH_TOKEN from the environment (if present) when calling the GitHub API in bootstrap.js, to avoid unauthenticated rate-limit failures during install/bootstrap.

Environment

• macOS (darwin), Apple Silicon
• Node v22.22.2, no global bun (used npx -y bun x gm-plugkit@latest spool per the documented "no bun" fallback)
• gm-plugkit@latest resolved to 2.0.2088