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; writers can run in parallel behind disjoint file boundaries and frozen interfaces. Only one UI driver controls the shared desktop at a time. 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)
• 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 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 thread shows how many commits behind the default branch it is — including when a teammate merges outside the app — and Update from main brings it current in one click through a platform merge. For open PRs with auto-merge armed, the platform also catches up behind PRs one at a time per project.

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.