Why every thread gets its own sandbox
Isolation isn't a nice-to-have for parallel work — it's the thing that makes it safe. Here's how we think about it.
If you've ever run two agents against the same working directory, you know the failure mode: one edits a file, the other reads a half-written version, and both end up confused.
Isolation makes parallelism safe
In darting.dev, every thread runs in its own cloud sandbox, branched from main. That single decision unlocks a lot:
- One thread reads the codebase while another rewrites it — neither sees the other's half-finished state.
- A thread runs the full test suite without slowing any other thread down.
- Heavy work — builds, Playwright, large installs — never touches your laptop.
main
├─ thread 1 sandbox + branch
├─ thread 2 sandbox + branch
└─ thread 3 sandbox + branch
Inside a thread, the lead agent delegates to sub-agents that share its sandbox — an explorer to map the code, a UI driver to record proof, a reviewer to audit the diff — so the isolation boundary is the thread, and the speedup inside it comes from delegation.
Stale state becomes a notification
The hard part of parallel work is staying in sync. When main moves — even from a teammate's merge outside the app — each thread sees exactly how far behind it is, and Update from main brings it current in a click (a merge, or a rebase if you want linear history).
That's much cheaper than re-reading the whole repo, and it removes the endless "go look at the code again" loop that plagues single-context agents.
The feedback loop stays tight
Isolation usually means things feel remote. We fixed that with a streamed desktop, a live terminal, and branch-aware diffs — so even though the work happens in the cloud, it feels like it's right in front of you.
Read more in the Isolated sandboxes docs.