5.8 KiB
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.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.