Skip to main content
Three commands, in the order you will want them.

​
Which version am I on

Why it works. This prints the version compiled into the binary you are actually running, and since 0.16.0 the commit it was built from, for example base 0.16.0 (build 1a2b3c4d5e6f), so two builds of one version can be told apart. It cannot be wrong about that. The gotcha. Do not confuse it with the version recorded in ~/.base-gbl/manifest.toml. That is tracked separately and can drift, most easily by swapping the binary by hand without touching the manifest. When the two disagree, base --version is the truth and the manifest is the thing to fix.

​
Is there a newer one

Why it works. It re-validates against the remote source rather than reading a cached answer, so it tells you the actual current state. The base binary is checked against GitHub releases; other ChrisAI components are checked against npm.

​
Updating

--force reinstalls even when you are already current, which is the way out of a state where the manifest and the binary disagree. Coming from 0.15, run base update once. base does not update itself while developer mode is on, and the 0.7.0 to 0.15.2 installers turned developer mode on for everyone. So most 0.15 installs show the weekly “base update available” banner instead of updating. One base update brings you to 0.16.0, which turns that installer setting off, and later updates arrive on their own.

​
Quieting the banner

Dismisses it for 24 hours by writing an expiry into the manifest. Why it works. The banner reads from manifest.toml, which holds the installed version, the install path and timestamp per component, plus an update-check block with when it last checked, how long between checks (7 days by default), any pending update, and the snooze expiry. The gotcha. That single file being the source of truth is exactly why a hand-swapped binary makes the banner nag about a version you already have. base update --force rewrites it.

​
What the update does by itself

Nothing to run, for you or for your Claude. The update swaps the binary in the background. The first session start on the new version then starts one more background process, base hook upgrade, and returns at once, so that start is no slower. That process brings each tier up to the new version, once, and records it in the tier’s .base/upgrade.json. For 0.16.0 it can change:
  • Your base data. Entries that belong to another of your workspaces move back there (or, when base cannot find that workspace, into a separate file in this one, so nothing is lost). A correction that names exactly one entry is linked to it. Small mix-ups in how entries point to the ones they replace are fixed. Repeated lines are removed, and only the newest 3 graph backups are kept.
  • Folder rules. A relative path trigger, such as notes, is written out as the full path it already meant.
  • Starter commands. A *base, *handoff, *fork or *end you never edited is replaced by this version’s text. One you edited is left as it is.
  • The old memory limit. The 0.15 installer’s [signal] max_chars = 2000 is removed, so Claude gets up to 4,000 characters of your saved notes. base config set budget.memory_chars 2000 sets the lower limit again.
  • Developer mode. If your base.toml still has the line the 0.15 installers wrote, developer mode is turned off at the next session start, with a paragraph saying so before anything else. One you turned on yourself stays on.
Every change is backed up first. The next session start says what changed in a few plain sentences per change, each with the command that undoes it, and the start after that says nothing more:
base doctor --restore puts back only a backup base made, a graph snapshot or a *.BAK-<date>-pre-<version> copy beside a config file, and refuses any other file. Session start also says which version base updated itself to, with a link to its notes on this site. A repair that fails leaves what it could not repair as it was, says so once with base doctor --fix --yes, and is not tried again for that version. [graph] auto_migrate = false turns all of it off. The one case that needs a person: a workspace folder you renamed after base wrote data for it. base doctor explains what it found and leaves it alone.

​
The help skill

base update also refreshes the bundled base-help skill in ~/.claude/skills/base-help/, from the release it just installed. That step is best effort: offline, or before the release’s files are published, the binary still updates, the skill stays as it was, and base doctor reports the drift. base install refreshes it too. This matters more than it sounds, because the skill is the answer surface. Its answer bank stamps itself with the version it was checked against, and it is written to treat every answer as a lead to re-verify when your installed version does not match that stamp.

​
After an update

Confirm the version moved, the graph is still sound, and your star commands still load. A commands.toml that stops parsing takes every star command in that tier with it silently, and base doctor is what tells you.

​
Next

Coach mode

The bundled skill, and why keeping it current matters.

Known issues

Behaviour that will surprise you, checked against the version that ships today.