Docs · Releases
Changelog
What shipped, and when. The list starts with the version that is on the update channel today and grows forward from there.
This list starts with the first published build. There is no earlier history here, because there was no earlier release a customer could install — the work before it was never handed to anyone. Rather than reconstruct it from memory, the record starts where the artefacts do and grows forward.
What is listed here
Two things ship on their own schedules, so both are named in every entry that changes them.
| Part | Versioned as |
|---|---|
| The client — desktop app and daemon, released together | A short version like 0.1.1 |
| The engine — the signed Chromium build profiles run in | A Chromium version like 150.0.7871.186 |
They move independently: a client release may keep the engine it had, and a new engine can be installed under a client you already run. What is fixed is the direction — a client states the oldest engine it will work with, and the engine is published before the client that requires it.
How an update reaches you
The desktop client checks a signed feed when it starts, downloads a newer version in the background, and then waits: a banner tells you it is ready, and the installer runs when you next quit or restart the app — never in the middle of your work. Two checks stand before that installer. The file's SHA-512 has to match the feed manifest, and its signature has to verify against the release key compiled into the app. If either fails, nothing is installed and the app says so plainly rather than burying it in a log. The Help menu shows which app and daemon version you are on, and can check for an update on demand.
A published version can also be withdrawn. The client reads a signed recall list before it downloads anything, declines a version that is on it, and tells you the reason — including when the version you are already running has been recalled.
The engine has its own path — a local registry you drive from the command line, so an engine version is a decision you make rather than one that happens to you:
| Command | What it does |
|---|---|
engine list | Shows the installed builds and which one is pinned |
engine install | Adds a build from an archive or URL, verifying it on the way in |
engine update | Applies a signed delta instead of downloading the whole build |
engine verify | Re-checks an installed build against its signature and file manifest |
engine pin | Makes a version the one profiles launch with |
engine rollback | Returns to the previously pinned build |
Because the previous build stays installed until you remove it,
engine rollback is one command and needs no download. The Windows
client keeps this in step for you: it provisions an engine on first start and, after
an app update, brings the engine up to whatever the new client requires.
Releases
0.1.1 — 2 August 2026
The first published build, and the one on the update channel today. It is the whole product rather than a change to it:
- Windows desktop client. A per-user installer that needs no administrator rights. It bundles and supervises the daemon, serves the management UI, fetches and verifies the engine on first start, and shuts the daemon and its browsers down when you close it.
- Self-hosted Linux daemon. A signed single binary for x86-64, built against an old enough glibc to run on current distributions. Same daemon, same API, same four interfaces as the Windows client.
- Engine 150.0.7871.186 or newer is what this client requires; it refuses to settle for an older build and provisions one that satisfies it.
- Signed updates end to end. Client, installer and update manifest are all signed with the same key the engine is signed with, and the client verifies that signature before applying anything.
There is no 0.1.0 entry above this one. That version was tagged and its
build failed before anything was published, so nothing under that number ever
existed to install.