Nothing lives in the sandbox
Your workspace tree is an encrypted git bundle in Isolation's storage. Each session works on a session/<id> branch; save merges back with compare-and-swap.
Your code lives in your workspace hub, not in the sandbox. A sandbox is a container on one of your organization's servers, and the server is a machine that can be reinstalled, stopped or thrown away. Neither holds the durable copy. The durable copy is a git bundle of /workspace, encrypted on the server before it leaves, stored in Isolation's storage and keyed to your workspace. Every session checks it out, works on its own branch, and merges back when you save.
That is the whole design, and it is what lets a session finish with /stop, resume on a different server, or survive a server whose disk is gone.
Where the bytes are, honestly
The workspace tree is stored on Isolation Cloud, in the object store behind it. It is stored encrypted: before the server uploads a bundle it encrypts it with AES-256-GCM under a key derived for that workspace, and the cloud only ever proxies and stores ciphertext. The server gets a time-bounded bearer for the workspace's bundle at launch, minted only for the member who owns the workspace, so a leaked launch envelope does not become permanent access.
Secrets are not in there. Environment values, repo tokens and SSH keys travel separately, sealed to the server, and are never written into the bundle or committed to git; see how secrets travel. A workspace export is a tar.gz of the definition and the file tree with every credential stripped.
The repos you clone keep their own git and their own remotes. They sit under /workspace but are excluded from the workspace tree, so a repo's history is pushed to GitHub the way it always was, and the bundle carries what surrounds them: notes, scripts, agent memory, generated files, anything you keep outside a repo.
How a session gets its own branch
Launch restores the bundle into a fresh sandbox and checks out session/<id> off main. A brand-new workspace has no bundle yet; the server initializes main from a deterministic root, so two sessions that start empty still share a history and merge cleanly later. The server remembers the bundle's ETag for the life of the session.
main ──●──────────────●──── (hub, encrypted bundle)
\ /
●──●──●──●─┘ session/3f9a12c0Everything you and your agents do happens on that branch, in the container. Until you save, the hub does not know about it.
Save, and what compare-and-swap means
/save commits the session branch, merges it into main with a merge commit, bundles the whole repository and uploads it with If-Match: <etag>. The hub accepts the upload only if the bundle it holds is still the one this session started from.
If another session of the same workspace saved first, the hub answers 412 and nothing is written. Your work is still on your branch, in your container, untouched. Run /sync: it fetches the hub's new main, merges it into your session branch, and on a clean merge you save again and the second upload goes through. Two sessions never clobber each other, and no save is ever partial.
If the sync merge conflicts, the default stops and changes nothing. /sync resolve leaves git's conflict markers in the tree for you or an agent to fix, after which save completes the merge. /changes shows what the session has touched and how far ahead of the workspace it is; with refresh it also probes the hub (a conditional request that answers 304 when nothing moved) to tell you whether the workspace has moved on underneath you.
Save from the session screen can take a selection of files. Save from a chat or from an agent saves everything that changed.
Wipe the disk, lose nothing
Wipe any server's disk and the acid test holds: the hub has the last saved main, and every session branch that was ever saved is inside the bundle. Launch the workspace again on any server, Connected or Cloud, and the tree comes back. A Connected Server keeps a local bare copy as a warm cache to make the next launch faster, but the cache is disposable; the hub is the truth.
Resume works the same way across machines. Suspend a session on one server, and its snapshot and its branch let it come back where you left it; see suspend, resume, finish. Finish a session without saving and the container's uncommitted changes are gone, which is why /stop asks first.
The runtime under all this is OpenSandbox, which we run unmodified; the layering is in architecture and OpenSandbox.
Questions
Is my code stored on the server?
Only while a session runs. The durable copy is an encrypted git bundle in your workspace hub on Isolation's storage. Wipe the server's disk and nothing is lost.
Can Isolation read my code?
The bundle is encrypted end to end with a key derived per workspace before it leaves the server. Isolation Cloud stores and serves opaque bytes.
What happens if two sessions save at once?
The second save gets a 412 from the hub. Sync pulls the first session's changes into the second, then save merges and stores. No save ever overwrites another.