Updates & rollback

The promises#

• Your files are never touched. Your code, notes and agent history live outside the software that updates. Updating, rolling back and rebuilding all keep them, and we test that nightly against real releases: a sandbox is updated, rolled back and force-failed mid-update, and the files must survive all three.
• Updates are offered, never forced. A new release shows up as a card in your workspace saying what's in it, in plain words. Nothing updates while you're not looking, and nothing interrupts an agent mid-task without you choosing it.
• The worst outcome of an update is the sandbox you already had. An update that can't come up healthy puts your previous sandbox back by itself. On your own machine, the previous version then stays ready for 24 hours: if the new one keeps crashing, never becomes ready or loses its connection in that time, the machine goes back to it by itself, and the update card says what happened and why. Going back by hand is one press on the update card, or one command on the machine, on Linux, macOS and Windows alike.
• Breaking changes are flagged before you take them, not after. When an update removes or changes something you may rely on, its card stops looking routine: it becomes a warning naming what stops working and what to do instead, and asks you to read it before handing over the command. The changelog carries the same lines under a Breaking badge.
• Nothing we ship can take your data hostage. The sandbox runs on your hardware and your state is plain files on your disk. Stop updating, roll back, or leave entirely: everything you made is already yours, readable without us.

When a release reaches you#

As soon as it passes. A release is built, installed and verified on real machines before it is published, and the moment that finishes it becomes the version every download link and every update card offers. There is no waiting room: what the tests proved is what you get, and a fix reaches you the day it is written rather than two days later.

The trade is that we carry the risk on our side rather than yours. If a release turns out badly we withdraw it and put the previous version back centrally, in one step, and your sandbox simply stops being offered the bad one. A sandbox already running it is told so on its update card, with the way back beside it.

What can change freely#

The promise is narrow. Everything outside it can improve without ceremony: how screens look, how features work internally, defaults you never set. A changelog entry tells you when a change is worth noticing; the warning treatment is reserved for changes that take something away, so that when you see one it means it.

If an update went badly anyway#

Open the update card and take the rollback it offers: your files stay as they are and only the software moves back. A version you don't want can be skipped there too; the next release is offered as usual. If the sandbox doesn't come back at all, the page offers the same way back without it after a few minutes: a button in the desktop app, or a command to run on the machine that runs your sandbox. A sandbox we host goes back from its update card or the sandbox switcher, once we have kept the version it ran before.

If a settings file then reads as unreadable, that is usually the older version looking at a newer file, and the notice says so rather than asking you to fix something that is not broken.