jarvis-selfhost/CHANGELOG.md

# Changelog

What each published build changes for you, newest first.

The three images are versioned independently and their numbers are not meant to match — usually only
one of them changed. An entry says which artefact and which version, so `web 0.102.0` and
`api 0.81.0` sitting under the same date is the ordinary case, not a mismatch.

Every version published to a channel appears here. Nothing is written from memory afterwards: a build
cannot be published without its entry.

## api 0.84.0 · web 0.105.0 — 2026-08-21

**Ask for a licence from inside Jarvis.** Settings → Licence has a form: your company, somebody to
answer, roughly what you need. Send it and your provider gets it with your instance's version and
counts attached, so the conversation starts at "here is what fits" instead of "how many machines do
you have".

**An approved licence installs itself.** The request is signed by your installation, so the licence
is issued for that exact deployment and arrives on it at the next report — no key to copy, nothing to
paste, and no way to paste it into the wrong instance. You get the key by email as well, for your
records and in case you rebuilt the host while you waited. A decline comes back the same way, with
your provider's reason on the licence screen and in your inbox. You can withdraw a request you no
longer want, and ask again whenever something changes.

**Community instances now report, and this reverses what we told you this morning.** api 0.83.0 said
— here, and in the README — that an instance without a licence contacts nobody at all. That is no
longer true. A community instance now sends the same fields a licensed one does: counts, the version
it runs, its contract checksum and its public address, to `checkin.luxit.be`. No names, no
conversation content, nothing about what you administer; the README lists every field, and it is the
same list as before.

Why: we could not tell whether the community edition had reached anybody, or which builds were
running when we needed to warn people about one — and the request form above needs the same channel
to work at all.

**`JARVIS_TELEMETRY=off` in `.env` stops it completely**, and costs you nothing else: every
community allowance, every feature and every connected machine stay exactly as they are. What you
lose is the licence request form, which has nowhere to send. A licensed instance reports regardless —
that has always been part of what a licence is, and the licence screen says so.

If you would rather not report, set that variable before you upgrade. Nothing is sent until the
instance's first check-in after start-up.

**On the licence screen**: what leaves your network, the exact address it goes to, and whether
reporting is on at all — all three visible without opening a compose file.

## api 0.83.0 · web 0.104.0 — 2026-08-21

**Jarvis no longer needs a licence key to be useful.** An instance without one now runs the
**community edition** — 1 organization, 3 users, 5 agents, 10 assets — perpetually, free, with every
feature working and nothing reported to anybody. Install it, connect it to something real, and see
what it does before there is anyone to talk to. A licence raises those limits; it does not switch the
product on.

This replaces the behaviour of the last three days, where an instance with no key came up, accepted
its first administrator account and then refused everything else. **If you installed Jarvis and found
it would not let you create anything, this is the release that fixes it** — upgrade, and the
allowances above apply immediately. Nothing needs to be reset, re-run or re-entered.

**A licence that stops applying now falls back to the same allowances**, instead of refusing every
creation. Expired, withdrawn, or a key that will not verify: your instance keeps running everything
already set up and may still create up to the community numbers. There is no state left in which
Jarvis stops being usable over a billing question.

**Fixed: an unreadable licence key blocked every creation.** The licence screen said nothing was
being withheld, and something was — a key that lost a character in a paste resolved every limit to
zero. It now falls back to the community allowances, which is what the screen always claimed.

**On the licence screen**, a fresh install no longer shows a red "No licence" badge. It says
Community edition, lists what that allows against what you use, and states plainly that nothing is
reported. The refusal you get when a limit is full names the edition and what raises it.

Nothing else changes. No configuration, no migration, no new variable — `JARVIS_LICENSE_KEY` is now
documented as optional, and it always could be left empty.

## api 0.82.0 · web 0.103.0 · agent 0.27.0 — 2026-08-21

**Nothing changes in what these builds do.** They are identical in behaviour to api 0.81.0,
web 0.102.0 and agent 0.26.0, rebuilt so that every published image carries the same set of
registry labels: what the image is, where its documentation lives, and a link to this file. The
package page in the registry now says something useful to somebody who lands on it without
context.

Upgrading is worthwhile only for that. If you are running the previous three and reading this,
you already have everything they do.

**The earlier version tags have been removed from the registry.** Every build before these three
is gone; the `stable`, `dev` and `latest` channels point at them. If you had pinned an exact
older version in `.env`, that pin no longer resolves and `docker compose pull` will fail — pin
one of the versions above instead, or drop the pin to follow `stable`.

## api 0.81.0 — 2026-08-21

**Approving a plan now actually authorises it.** When Jarvis asks for consent on a whole plan and you
approve it, the steps that touch the machines the plan names are no longer confirmed one at a time.
Previously the approval bound nothing at all — the assistant was asked to honour it and the executor
never checked — so an approved plan still stopped at every step, and a read-only conversation could
be granted a plan it had no way to carry out.

The clearance is deliberately narrow. It applies only in the conversation the plan was raised in,
only to the machines the plan names, only up to a risk ceiling, and only for four hours. Anything
outside it still asks. It can never be wider than the approver's own access to those machines.

**Two ways somebody could get more than they should, closed.**

- Approving used to lend the approver's own permissions to the plan for the rest of the turn. Work
  now runs as whoever asked for it, which is what the audit trail already claimed.
- Deciding a plan asked nothing about whether the decider may touch the machines it names — the
  per-command confirmation had checked this for months and this path had not. It does now, for every
  machine in the plan. Refusing is never restricted: anyone who can see a plan is wrong may stop it.

**Wording that was not true.** A command that was waiting for a human when the server restarted used
to be reported as possibly having taken effect, and told you to go and check the machine. It never
ran — the confirmation happens before anything is sent — so it now says so.

If you have approval requests older than this release, they are recorded as expired. They were made
under the old behaviour, where approving authorised nothing; treating them as live permissions would
grant something nobody was asked for.

## web 0.102.0 — 2026-08-21

**The approval panel says what approving does.** It used to promise "Jarvis runs the steps below" and
"Nothing runs until you decide". Neither was true: a pending plan blocks nothing, and approving did
not run anything. It now describes the clearance you are actually granting — which machines, what
ceiling, how long — and the rejection notice no longer claims that nothing ran.

The per-command confirmation is unchanged. That one does hold the command until you answer.

## api 0.80.0 · web 0.101.0 — 2026-08-21

**The footer says which channel this instance follows**, beside the version numbers, when you set
`JARVIS_CHANNEL` in `.env`. Leave it empty if you pin exact versions — you then follow no channel,
and the footer shows nothing rather than a label that stopped being true.

## api 0.78.2 · web 0.100.2 — 2026-08-21

**Distribution channels.** Images now carry `stable` and `dev` tags as well as their version.
`stable` moves only after a build has run on the publisher's own instance; `dev` moves on every
build. `latest` is a second name for `stable`, so nothing that already used it has to change, and
the compose files default to `stable`.

A channel is a pointer and a version is a fact. Promotion copies the manifest of an image that has
already been published and run — it never rebuilds — so the bytes you receive are the bytes that were
tested, not a fresh build of the same source.

**Fixed: some builds reported their version as `dev`.** The version is stamped into the image and
shown in the footer; a build published without it said `dev` while being tagged, pinned and run
correctly. Affected api 0.78.0 and 0.78.1 and web 0.100.0 and 0.100.1.

## web 0.100.0 — 2026-08-21

**Recorded terminal sessions can be replayed** at the pace they happened, not only read as a finished
transcript. Idle time is compressed so a session that was mostly waiting is watchable, and how much
was skipped is stated. Sessions recorded before this release can still be read; they carry no timing,
so they cannot be replayed, and the panel says so rather than hiding the control.

## agent 0.26.0 — 2026-08-21

**The command is now `jarvis`.** `jarvis-agent` keeps working and will continue to: both names are
present on every machine, and an agent that updates itself gives itself the missing one. Uninstalling
is a verb — `jarvis uninstall` — beside `status`, `start` and `stop`. The old
`jarvis-agent-uninstall` command is unchanged.

`jarvis uninstall` refuses to run from inside a Jarvis terminal on the machine it is removing.
Stopping the service would kill the command mid-way, leaving the agent stopped and nothing
uninstalled, with no connection left to fix it through. Run it from an ordinary SSH session.

## agent 0.25.0 — 2026-08-21

Internal: the agent asks the machine which name its service is registered under rather than assuming
one. No visible change; it is what makes a later rename survivable.

## agent 0.24.0 — 2026-08-21

**Remote terminal on macOS.** Interactive shells now work on managed Macs, as they already did on
Linux and Windows. The session opens a login shell so the PATH matches what an administrator expects.

**Fixed: sessions were recorded as "closed" instead of "exited".** Typing `exit` ended the session
correctly but filed it as though it had been taken away, with no exit code. Sessions from before this
release keep the reason they were given.

**Fixed: a file descriptor and a thread leaked on every clean exit.** Only visible on machines that
stay up for a long time with many sessions.