Skip to content

Releases: BlockRunAI/blockrun-cli

v0.2.1 — core 0.1.1 + cli 0.2.1, published from CI with provenance

Choose a tag to compare

@VickyXAI VickyXAI released this 08 Aug 17:25

No functional change from 0.1.0 / 0.2.0. This release exists to close a supply-chain gap.

Why

0.1.0 and 0.2.0 were published from a laptop. Four CI attempts had died on EOTP — each package's npmjs.com Publishing access was rejecting every token type, and that was only diagnosed afterwards. Shipping the payment-signing takeover fix mattered more than the attestation at that moment, so they went out unsigned.

These versions publish through .github/workflows/publish.yml, so both carry a provenance attestation tying the tarball to this repo, this commit, and this workflow — verifiable in Sigstore's public transparency log.

@blockrun/core resolves wallet keys and signs x402 payments. It was the last package in this org without a verifiable build chain, which is the wrong package for that gap.

0.1.0 and 0.2.0 stay correct and installable. npm does not allow attaching an attestation to an already-published version, which is the only reason this is a new release rather than a re-sign.

Known, not fixed here

pnpm-lock.yaml pins @blockrun/llm at 3.9.0, not 3.10.0 — the release that moved the Solana packages to optional peers and keeps bigint-buffer (GHSA-3gc7-fjrx-p6mg, unpatched) out of dependency trees. Published consumers are unaffected; they resolve ^3.9.0 to 3.10.0 themselves. This repo's dev tree and CI still install the old one. Fixing it needs a real pnpm install to regenerate the lockfile, not a hand edit.

@blockrun/core 0.1.0 + @blockrun/cli 0.2.0 — payment-signing takeover fix

Choose a tag to compare

@VickyXAI VickyXAI released this 07 Aug 22:29

Security: a provider wallet could take over x402 payment signing

@blockrun/core's resolveFromFiles() consulted ~/.<app>/wallet.json files before the canonical ~/.blockrun/.session, returning whichever was modified most recently. Installing another product — or writing one file into the home directory — therefore changed which key resolvePrivateKey() handed to payment signing, across blockrun api, pay, chat, run, image, video, music, speech, and the data commands. scanWallets() also reported each file's self-declared address, so blockrun wallet recover could display an address the file held no key for.

  • resolveFromFiles() now reads .session → legacy wallet.key only. Discovered provider wallets never participate in automatic resolution.
  • scanWallets() derives each address from the discovered private key and drops unusable entries. The file's address field is no longer trusted anywhere.
  • WalletSource no longer includes "provider". Breaking for anything narrowing on that member.
  • Added listDiscoveredWallets() and adoptWallet(address) — the deliberate migration path. Adoption matches on the derived address and backs up the outgoing .session first, so funds are never stranded.

Why the CLI ships as 0.2.0

Two releases never reached npm before this one. @blockrun/cli 0.1.1 was tagged and changelogged on 2026-07-17 but never published — npm's latest was still 0.1.0 — and core 0.1.0 sat built-but-unpublished while @blockrun/cli@0.1.0 kept resolving @blockrun/core@^0.0.3, which carries the defect above.

A ^0.0.3 range cannot reach 0.1.0, so publishing core alone would have fixed nobody. The CLI ships too, with the range moved to ^0.1.0. 0.2.0 is the first build users can install that contains either the 0.1.1 work or this security fix.

Also in this release

  • Removed a vulnerable undici dependency chain, with a dependencies.test.ts guard. @blockrun/llm moves ^3.5.0^3.9.0.
  • Hardened the CLI security boundaries (cli.ts, chat.ts, x402.ts, dispatch.ts, new http.ts, core/output.ts).
  • HTTP timeout made portable across Node versions.
  • blockrun wallet list and blockrun wallet adopt <address> added; wallet recover now reports entries in true resolution order and marks exactly one active.

Release automation

The repo had no publish workflow — releasing meant remembering to run npm publish twice, in the right order, by hand, which is how both prior releases were lost. .github/workflows/publish.yml now publishes on release: core first (the CLI's range must be resolvable before the CLI exists), then the CLI, each guarded against double-publishing, both with --provenance. It uses pnpm publish, not npm publish — only pnpm rewrites the workspace:^ protocol into a real semver range.

Verified: pnpm install --frozen-lockfile clean, build + typecheck clean, 57/57 tests pass, CI green on Node 20/22/24 including the packed-artifact smoke test that plants a newer provider wallet.json and asserts .session still wins.