Isolated sandboxes

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.

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
• A terminal you can stream and type into
• A desktop with an in-VM browser, so logins, OAuth, and cookies all work normally

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