helmor-bump-vendors

name

helmor-bump-vendors

description

Bump or upgrade the pinned versions of Helmor's bundled agent CLIs, SDKs, and supporting binaries — Claude Code + claude-agent-sdk (lockstep), Codex, Cursor SDK, OpenCode, Kimi, Pi, and gh / glab / cloudflared / llama.cpp / Node. Encodes exactly which files to edit (`sidecar/package.json`, `sidecar/scripts/vendor-platform.ts`), how to source each version and compute its SHA256, the Claude SDK↔CLI lockstep rule, npm dist-tags caveats (latest vs next vs stable), the cross-arch (arm64+x64) SHA requirement, and the mandatory verification gates. Use whenever the user wants to upgrade / bump / update / refresh a bundled agent CLI or SDK version, check whether a vendor is behind latest, or run a dependency version sweep in the Helmor repo.

Helmor Bump Vendors

Standardized procedure for upgrading the third-party agent CLIs, SDKs, and helper binaries that Helmor pins and bundles. Goal: a correct, verified bump with no guesswork about where versions live, how to source each SHA256, or what to run before declaring it done.

The pin sites

Every bundled version is pinned in one (or both) of these files:

• sidecar/package.json — npm dependencies. Covers SDKs (imported in TS) and the npm-distributed CLIs whose native binary is staged from node_modules (@anthropic-ai/claude-code, @openai/codex, opencode-ai).
• sidecar/scripts/vendor-platform.ts — version constants + per-version SHA256 tables for every staged binary. Source of truth for what gets bundled into the release.
• sidecar/scripts/stage-vendor.ts — staging logic. Only edit it when a vendor's archive layout changes (rare; see codex/cursor notes in references/vendors.md).

Vendor classes (determine the change-set)

Class	Vendors	What to edit	SHA256?
A. npm SDK only	@anthropic-ai/claude-agent-sdk, @cursor/sdk, @opencode-ai/sdk, @earendil-works/pi-*	package.json line	No — plain npm dep
B. npm-distributed staged binary	claude-code, codex, opencode	package.json line + SHA256 table key in vendor-platform.ts	Yes — from npm tarball
C. GitHub-release staged binary	kimi, gh, glab, cloudflared, llama.cpp, node	<NAME>_VERSION const + SHA256 table in vendor-platform.ts (NOT in package.json)	Yes — source varies

Per-vendor exact pin location, SHA256 source, and gotchas live in references/vendors.md — read the relevant section before editing.

Workflow

1. Scope. Confirm which vendors to bump. For each, open references/vendors.md for its class, pin location, SHA source, and gotchas.
2. Find the target version. Check LIVE — never trust memory; dist-tags flip within hours.
   • npm: bun -e 'console.log((await (await fetch("https://registry.npmjs.org/<pkg>")).json())["dist-tags"])' Target latest (the stable channel). next is a prerelease — do not pin it unless the user explicitly asks. claude-code also publishes a conservative stable tag that lags (e.g. 2.1.179); Helmor tracks latest, not stable.
   • GitHub-release vendors: check the repo's Releases (or https://api.github.com/repos/<owner>/<repo>/releases).
3. Edit the pins (package.json and/or the _VERSION const). Apply the Claude lockstep rule and any per-vendor gotcha from the reference.
4. cd sidecar && bun install — pulls the new versions. Sanity-check: resolved versions are correct, any removed deps dropped from bun.lock, transitive deps you rely on are still present.
5. Compute + fill SHA256 for class B/C. Use scripts/npm_vendor_sha.sh for B; see the reference for C. Both arm64 and x64 are mandatory (see Critical rules).
6. Run the verification gates (below) — all must pass.
7. Create release metadata. Once the gates pass, invoke the /helmor-release skill to draft the changeset (and an in-app announcement if the bump warrants one). Don't skip this — a vendor bump is a user-visible change and needs a changeset. A routine bundled-agent refresh is typically a patch changeset with no announcement; the body should name the user-visible change (which agents moved to latest), not the internal cleanup (Pi removal, pin tidy-ups, doc fixes).
8. Report: current → target per vendor, breaking-change assessment, gate results, exact files touched, and the changeset created. Leave commit / PR to the user unless asked.

Critical rules (the non-obvious parts that cause bad bumps)

• Claude lockstep. @anthropic-ai/claude-agent-sdk@0.3.X and @anthropic-ai/claude-code@2.1.X share patch X and ship together — always bump both to the same X. Verify: the SDK's node_modules/@anthropic-ai/claude-agent-sdk/package.json carries claudeCodeVersion: "2.1.X". Only claude-code (the staged binary) needs a SHA256 entry; the agent-sdk is a plain npm dep.
• Cross-arch SHA is mandatory. Every class B/C SHA table needs both arm64 and x64. CI cross-builds the x86_64 bundle on an arm64 runner. On a native-arch host the build uses node_modules directly and does not verify the SHA — so a wrong/missing x64 entry passes locally but breaks CI. Always compute both from the tarballs.
• dist-tags drift. Re-check latest at bump time even if you "just looked" — a newer patch can be promoted from next to latest within hours.
• SHA table = rolling history. The tables keep a few recent version keys (cache is version-keyed, so old keys coexist harmlessly). Add the new key; keep the prior one. If you are superseding an uncommitted entry you added this session, replace it (don't stack) for a clean diff.
• Layout-change watch. Codex ships a self-describing codex-package.json descriptor; after a bump, diff it — a layoutVersion change or new field means stage-vendor.ts needs review. See references/vendors.md for codex, cursor (Node engines floor + phantom dep), and kimi (ACP protocol version) specifics.

Verification gates (run in order; all must pass)

cd sidecar && bun install        # 1. installs targets; confirm versions + dropped deps in bun.lock
cd sidecar && bun run typecheck  # 2. catches SDK API breaks (removed/renamed exports) — main breaking-change detector
cd sidecar && bun test           # 3. sidecar unit tests
# 4. MANDATORY after ANY agent CLI/SDK bump — validates the stdout event-shape contract the Rust pipeline depends on:
cd src-tauri && cargo test --test pipeline_scenarios --test pipeline_fixtures --test pipeline_streams
cd sidecar && bun run build      # 5. full staging + compile; a wrong SHA256 hard-fails here (downloads + verifies kimi / cross-arch)

What each gate proves:

• typecheck is the real breaking-change detector for SDK bumps (removed/renamed exports, changed types).
• cargo pipeline tests replay stored fixtures, so they catch pipeline-code regressions — not new event shapes from a newer binary. For the latter, read the upstream changelog (focus on the stdout event JSON: codex item/,turn/,thread/ methods; claude SDKMessage/stream blocks; opencode message.part; kimi ACP session/update) and capture fresh fixtures if the shape moved.
• build is the only gate that exercises SHA256 verification and the staging layout.

Breaking-change diligence

Before pinning, read the upstream changelog/release notes across the current→target window. Most agent-CLI patch bumps are additive; the risks that matter for Helmor are (a) SDK export/type changes (typecheck catches these) and (b) stdout event-shape changes (the Rust pipeline contract). Tag each notable change affects Helmor or no impact with reasoning, and surface it before bumping.

Tools in this skill

• scripts/npm_vendor_sha.sh <claude-code|codex|opencode> <version> — downloads the darwin arm64 + x64 npm tarballs and prints their SHA256, ready to paste into the vendor-platform.ts table. (Class B only. Class A SDKs need no SHA; class C sources differ — see the reference.)
• references/vendors.md — exhaustive per-vendor map: integration mechanism, exact pin location, SHA256 source/recipe, gotchas, and post-bump steps.