> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basemode.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Released versions of base, newest first. Each entry covers what changed in the command surface and anything that affects an existing install.

base updates itself. Session start checks for a new release and installs it in a detached background process when there is one, so there is nothing to download and nothing to run. The swap is an atomic rename: the session you are in keeps the binary it started with, and the next one comes up new.

If you would rather drive it by hand:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
base config set update.auto false   # pin this machine
base update --check                 # is there something newer
base update                         # install it now
```

Setting `devmode.enabled` also suppresses the background update, so a base you built from source is never clobbered by a release binary.

<Note>
  This changelog starts at 0.13.2. Earlier releases are tagged in the repository but are not written up here.
</Note>

## 0.13.2

*The current release.*

**Reading what changed.** `base changes` reads the graph change log: every successful write, as JSON, written beside the graph file it describes.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
base changes --cursor
base changes --since 48210
base changes -g --cursor
```

The cursor is a byte offset rather than a sequence number, so it needs no separate counter to stay in step, concurrent appenders do not break it, and a reader resumes from exactly the value it was handed. Records now also carry a fact-shaped `ops[]` delta alongside the SPARQL, so a reader can tell what a write did without parsing the query.

**Syncing a graph from elsewhere.** `base graph apply-ops` reads fact operations as JSON on standard input and applies them in one transaction.

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
base graph apply-ops < ops.json
base graph apply-ops --global < ops.json
```

It prints how many were applied, skipped as duplicates and skipped as unknown. An invalid operation exits nonzero having applied none of them, so a partial write is not a state you can reach.

**Fixed in this line, worth knowing if you are coming from an earlier build:**

* `--global` resolved by searching upward for the nearest `.base/`, and on a machine that had only run `base install` the search climbed past the global tier and took a workspace tier instead. Every `-g` command then wrote to the wrong graph. It now resolves to its one fixed location directly.
* The update banner compared the manifest against the latest release rather than against your running binary, so a hand-swapped binary nagged forever. Session start now reconciles the recorded version against the running one first.
* `base commands import` corrupted `commands.toml` on any rule containing a newline, tab or backslash, and the loader swallowed the parse error. Both halves are fixed, and `base doctor` now reports a config file it cannot parse.
* The "AST graph not yet populated" hint checked a path maps are no longer written to, so it fired forever. It now resolves the same way queries do.

[Known issues](/known-issues) carries the full status of each, including the two that are still live.

***

Entries from here forward follow the same shape: the version, its release date, what changed in the command surface, and anything that needs attention on an existing install.