Git worktrees vs cloud sandboxes for coding agents

Compare the boundary each option creates

Git describes a linked worktree as another working tree attached to the same repository. It has its own working files, index, and HEAD, while sharing repository data. Creating one does not provision a machine or start a development server.

Sandbox implementations differ. Check whether the service provides a container, a virtual machine, or another boundary, and ask what is shared. The word "sandbox" alone does not describe network access, persistence, or available credentials.

Create two checkouts without disturbing the current one

For an existing Git repository, these commands create new branches from your current commit in two new sibling directories. Pick unused branch and directory names. Uncommitted edits in your current checkout are not part of that starting commit.

git status --short
git worktree add -b agents/search-copy ../search-copy HEAD
git worktree add -b agents/search-tests ../search-tests HEAD
git worktree list
git -C ../search-copy status --short
git -C ../search-tests status --short

Run each agent in its assigned directory. Install dependencies using the repository's normal setup instructions, and confirm the selected branch before editing. A fresh working directory may need generated assets or ignored configuration that the existing checkout already has.

Avoid pointing both agents at one mutable output directory outside their checkouts. For example, a test harness that writes every screenshot to the same absolute path can mix artifacts even when the source files live in separate directories. Include the branch or task identifier in those output paths.

A directory change does not allocate a new port

Two local apps trying to listen on the same address and port can collide. Node documents EADDRINUSE for a listener whose address is already occupied. Running the apps from different worktrees does not change that address.

You can demonstrate explicit port assignment with Node installed. Run each command in a different terminal. These tiny HTTP servers return a label so you can tell which one the browser reached. Stop each with Ctrl+C after inspecting it.

# Terminal one: open http://127.0.0.1:4311
DEMO_PORT=4311 DEMO_LABEL=search-copy node -e 'require("node:http").createServer((req,res)=>res.end(process.env.DEMO_LABEL)).listen(Number(process.env.DEMO_PORT),"127.0.0.1")'

# Terminal two: open http://127.0.0.1:4312
DEMO_PORT=4312 DEMO_LABEL=search-tests node -e 'require("node:http").createServer((req,res)=>res.end(process.env.DEMO_LABEL)).listen(Number(process.env.DEMO_PORT),"127.0.0.1")'

Those environment variables work because the example reads them. Your application may use a command-line flag, configuration file, or another variable. Check its startup command instead of assuming that setting PORT changes every framework or service. Update API origins and browser test configuration when the app's address changes.

Trace connections beyond the local machine

Separate computers can still point to the same database. If one agent resets a shared test account while another tests its checkout, the second agent can fail for reasons unrelated to its patch. The same problem appears with object storage, email inboxes, and shared job queues.

Record each environment's service destinations before starting parallel work. Use disposable databases or task-specific namespaces when the tests change data. A namespace works only if every relevant query and cleanup path respects it; a label in the session title cannot protect shared rows.

Keep migrations coordinated. Two agents can independently create valid migrations that assume different schema states. Choose their application order and test the sequence against a disposable baseline before release. Neither filesystem separation nor network isolation resolves that dependency.

Choose from the work your agents need to run

Start with local worktrees when the setup already runs reliably on your machine and tasks need modest resources. They are useful for reviewing one branch while another agent edits a different branch, or for independent changes whose checks do not mutate shared services.

Consider separate sandboxes when several agents must run full applications, toolchains disagree, or the work should execute away from a developer's laptop. Include setup time and environment cost in the comparison. A task that requires private network access may also need a different deployment arrangement.

Uno gives each agent session its own cloud computer; its security page describes the session boundary. That helps separate local execution. You still choose the repositories, service connections, and acceptance checks appropriate to the task.

Identify the environment in the review handoff

Ask for the branch and commit tested, application address, relevant service configuration, and exact checks performed. Never include secret values in that handoff. Reviewers need enough information to tell whether a screenshot or test result belongs to the proposed change.

After combining patches, check their shared behavior. Two agents can avoid every port collision and still implement conflicting permission rules. The environment keeps execution separate; the parallel agent workflow assigns responsibility for bringing the results together.