# Isolated sandboxes

> Why every thread runs in its own cloud environment, and what that buys you.

Every thread in darting.dev runs inside its own cloud sandbox, branched from `main`. There is no local execution — all file operations, commands, and git happen inside sandboxes.

## One sandbox per thread

A thread is a conversation on its own git branch, and it gets its own sandbox: a full Linux environment with a clone of your repo at that branch. Because each thread is sealed off from the others, you can run many at once and they can never step on each other.

```text
main
 ├─ thread 1 · sandbox + branch   payments feature
 ├─ thread 2 · sandbox + branch   search refactor
 └─ thread 3 · sandbox + branch   bug fix
```

That's what makes parallelism safe:

- One thread's edits can never break the tests another thread is running.
- Compute-heavy work — Playwright, builds, full test suites — runs in the cloud, never on your laptop.
- No worktrees to juggle, no `.env` to copy, no remembering which port a server runs on.

## A swarm inside a thread

Within a single thread, the lead agent doesn't do everything itself — it **delegates** to specialized sub-agents that share its sandbox, so they all see the same live working tree:

- An **explorer** maps the codebase so the lead doesn't burn its own context doing it.
- A **UI driver** opens the app in a real browser and records a video of the change working.
- A **reviewer** audits the diff for security and correctness.

Read-only helpers can run side by side; the agents that drive the browser or write code take turns on the one shared environment. Isolation between _threads_ is what lets you parallelize; delegation _within_ a thread is what keeps the lead agent fast and focused.

## What's in a sandbox

Each sandbox is a full Linux environment with:

- A clone of your repo at the thread's branch
- Installed dependencies and a running dev server (from the project's [run config](https://darting.dev/docs/run-config-and-snapshots/))
- A terminal you can stream and type into
- A desktop with an in-VM browser, so logins, OAuth, and cookies all work normally

[Desktop, terminal & logs](https://darting.dev/docs/desktop-terminal-and-logs/) covers the live surfaces in detail.

## Staying in sync with main

The hard part of parallel work is not drifting from `main`. darting.dev surfaces it instead of hiding it: the branch graph shows exactly how many commits behind `main` each thread is — including when a _teammate_ merges outside the app — and [Update from main](https://darting.dev/docs/update-from-main/) brings a thread current in one click (a merge by default, or a rebase if you want linear history). Threads with an open pull request also pull in merged changes at the start of each turn.

That's cheaper than re-reading the whole repo, and it removes the endless "go look at the code again" loop.

## Keeping sandboxes warm

Sandboxes pause when idle to save resources and resume on demand. While a desktop, terminal, or app-log view is on screen, a keepalive heartbeat ensures the environment is never paused out from under you. New threads claim a pre-warmed sandbox from a pool, so they start fast.