abx.
Using ABX

Upgrading

Staying current means you pick up fixes and new commands as they ship. ABX is in an alpha line, and npm's latest tag points at it — so a plain install always resolves the current release, and upgrading is one command.

Check your version

abx version

When something looks broken, check this first

A stale install rarely announces itself as a version problem. It tends to show up as:

  • a command these docs describe that your abx help has never heard of
  • … is not a function, or an internal-looking crash partway through a command that had been working
  • a deploy that can't find a canonical contract, or resolves one to an address that no longer exists

Those are all the same fix. Run abx version, compare it against the published versions, and upgrade before debugging anything else. While ABX is pre-1.0 the canonical singletons get redeployed and the shipped address manifest repointed along with them — so an old CLI can be perfectly self-consistent and still wrong about the chain.

Upgrade

Upgrade the same way you installed. If you installed once, globally:

npm install -g @artblocks/abx-cli@latest
abx version

If you pinned it per-project:

npm install --save-dev @artblocks/abx-cli@latest
npx abx version

Then resync the agent skill, which is version-locked to the CLI:

abx skill install

Keep the skill in sync

The agent skill and the CLI are co-versioned — the skill's SKILL.md frontmatter carries the exact version it was cut with, stamped at release to match the CLI. Upgrading the CLI does not move a skill copy you installed earlier, so refresh it whenever you upgrade:

abx skill install        # re-installs the bundled, version-locked skill for the current CLI

Because the version lives inside the skill file, abx detects a copy that has fallen behind — no matter how it was installed — and nudges you to re-run this; abx doctor reports the match explicitly. A well-behaved agent handles both halves itself: it upgrades the CLI when it sees the notice, resyncs the skill, and reloads before it deploys anything.

(The cross-agent npx skills add ArtBlocks/abx installer becomes available once the ABX repository is public; a git-sourced copy is not version-locked to your local CLI, so the same drift check is what keeps you honest. The exact command is npx skills add ArtBlocks/abx --skill abx-self-host.)

The update check

abx checks npm for a newer release every few hours (the result is cached) and, when one exists, prints a short upgrade hint to stderr — so it never interferes with output an agent may be parsing. It is a no-op when offline and in CI, and it never changes anything on its own: it tells you, you decide.

Because this lives in the CLI itself, it works no matter which agent drives abx — Claude Code, Cursor, Codex, and peers all get the same nudge. It stays correct across release lines, too: it asks npm both for latest and, when you're on a prerelease, for that prerelease's own channel, and reports whichever is newer.

To turn it off (in CI it's already off) → CLI reference.

Release notes

CHANGELOG.md ships inside the package (see its files list), so the notes for the version you have are readable offline and always match the install. Every published version is listed on npm.

If a release moved the canonical singletons

A redeploy of the shared singletons (generator, renderer, factories) repoints the manifest your CLI ships with, so a new deploy uses the new addresses. Already-deployed contracts are unaffected — they hold their own references and keep resolving against the pair they were deployed with. abx verify <address> confirms it against the chain. So a moved address in the changelog is not something you need to act on for existing work; it only matters if you are comparing two versions' dry-run output.

On this page