EXAMPLE 01
  • agents
  • worktrees
  • git

Parallel coding agents

Several coding agents on one repo, fully isolated from one another.


The problem

Two agents in one checkout trip over each other: one switches branch while the other is mid-edit, one’s git stash swallows the other’s work, both run the dev server on the same files. You want one working tree and one branch per agent, and a container for each so their processes stay apart too.

That is what repeat instances do. The first devsandbox run of a sandbox mounts the repo itself; every further instance of the same repo gets its own git worktree under the config dir, on its own branch, in its own container. Gitignored files a fresh checkout lacks, like .env, are copied or linked in for you.

Let your agent set this up

Config

devsandboxes.toml
[sandbox.app]
folder = "../app"          # your repo, next to this config dir
image = "node:22"          # any image with the repo's toolchain
caches = ["npm"]           # one npm cache for every instance
worktree-link = [".env"]   # one .env, shared by every instance

# Your  login and settings, from the host.
mounts = ["source=${localEnv:HOME}/,target=/root/,type=bind"]
containerEnv = {  = "/root/" }

[sandbox.app.postCreateCommand]  # once, when an instance is created
deps = "npm install"
agent = "npm install -g "
devsandboxes.toml
[sandbox.app]
folder = "../app"          # your repo, next to this config dir
image = "node:22"          # any image with the repo's toolchain
caches = ["npm"]           # one npm cache for every instance
worktree-link = [".env"]   # one .env, shared by every instance

# Your  login and settings, from the host.
mounts = ["source=${localEnv:HOME}/,target=/root/,type=bind"]

[sandbox.app.postCreateCommand]  # once, when an instance is created
deps = "npm install"
agent = "npm install -g "

On macOS keeps its login in the Keychain: run /login once in any instance.

Try it

One instance per task:

TERMINAL
devsandbox run app --name fix-login                                 # your checkout, ../app
devsandbox run app --name add-profile-pic --branch feat/profile-pic  # its own worktree
devsandbox ps
  • --name: the instance name.
  • --branch: the branch name (default sandbox/<name>).

Start in each:

TERMINAL
devsandbox exec -it fix-login 
devsandbox exec -it add-profile-pic 
TERMINAL
devsandbox exec -it fix-login 
devsandbox exec -it add-profile-pic 

When a task is done, push its branch (ssh and git push) and remove the instance, container and worktree:

TERMINAL
devsandbox rm add-profile-pic

How it works

  • Worktrees live in .worktrees/<name> next to devsandboxes.toml; rm deletes them with the container.
  • worktree-link symlinks one shared copy into each worktree; worktree-include or a .worktreeinclude copies instead.
  • ’s config dir is mounted from the host: one login for every instance.

Agent instructions

Prompt for your coding agentPaste into Claude Code, Codex or any agent with a shell.

Set up devsandbox so several sessions can work on my repo at <repo path> in parallel, each in its own sandbox instance on its own git worktree and branch.

  1. Read the devsandbox-cli and config-toml-spec skills first (load them if they are installed, otherwise read them from https://github.com/Nemikolh/devsandboxes/tree/main/skills). Follow them over your own assumptions: unknown config keys are hard errors.
  2. Find my devsandbox config dir: the folder holding devsandboxes.toml, passed to devsandbox as -C <config dir>. If you cannot tell which one, ask me.
  3. In devsandboxes.toml, add a [sandbox.<sandbox name>] whose folder points at <repo path> (relative to the config dir), with an image that has the toolchain the repo needs. Install in postCreateCommand and mount its host config dir (its login) into the container.
  4. Put gitignored files every instance needs, like .env, in worktree-link.
  5. Validate with devsandbox -C <config dir> ls and fix every error it reports before going on.
  6. Start one instance per task with devsandbox -C <config dir> run <sandbox name> --name <task> for each of <task names>.
  7. Check devsandbox -C <config dir> exec <task> git status in each instance shows its own branch, and devsandbox -C <config dir> exec <task> --version works.
  8. Ask me before anything destructive: devsandbox rm, gc, rebuild --force, service rebuild, deleting files or branches.
fill in before sending Agent skills (opens in a new tab)

Source: site/src/content/examples/parallel-agents.mdxEdit this page on GitHub(opens in a new tab)

MENU /
View on GitHub
EXAMPLES
All examplesEvery recipe on one page.Parallel coding agentsSeveral coding agents on one repo, fully isolated from one another.One shared PostgresOne development database for all your sandboxes and their instances.Private services per instanceEvery instance gets its own Postgres and Redis, so agents never touch each other's data.Shared package cachesNew sandboxes stop downloading the same packages again.ssh-agent and git pushAgents push over ssh with your host's keys, which never enter the container.Port forwarding on demandOpen a sandbox's dev server or database from your host, without restarting anything.Attach VS CodeOpen any instance in VS Code with one key.devcontainer FeaturesAdd Node, Rust or the GitHub CLI to any image, in TOML.Babysit pull requestsAn agent keeps your open PRs merged with their base, and pings you when it can't.Port a devcontainer.jsonTurn an existing devcontainer.json into a devsandbox config.