What you will build
A two-task integration plan. One task adds a parser edge-case test; another updates its usage documentation. Both begin from the same source commit and produce independently reviewable artifacts.
- One baseline SHA
- Two private sandboxes
- Independent evidence packets
- Serial review and integration
Conceptual flow. Follow the lesson for prerequisites, exact commands and verification limits.
Read the mechanism
Separate sandboxes reduce process and filesystem interference, but sharing the same direct host mount reintroduces a common working tree. Two Git processes can race over the index, branch or lock files. Independent execution is not independent integration.
For clone mode, create each sandbox from the main checkout at the same clean revision. Each receives a private clone. For direct mode, use explicitly separate working directories or Git worktrees. Remember that clone creation from a linked worktree is currently unsupported.
Other shared resources remain: provider rate limits, remote branches, external services, host CPU and memory, and optional shared skills. A read-write skills store can influence another agent later, even without direct sandbox networking.
Worked example · two named tasks
From a clean synthetic main checkout:
git rev-parse HEAD
sbx create --clone --name handbook-tests --skills off --cpus 2 --memory 2g shell .
sbx create --clone --name handbook-docs --skills off --cpus 2 --memory 2g shell .
sbx lsKeep a task map:
| Task | Sandbox | Allowed files | Integration order |
|---|---|---|---|
| Add edge-case test | handbook-tests | parse.test.mjs | First |
| Explain input syntax | handbook-docs | README.md | Second |
Perform harmless edits manually or with approved agent integrations. Commit each task in its own clone. Fetch both sandbox remotes, inspect each diff, then integrate serially into a dedicated review branch. Re-run the combined test suite after the second integration; individually passing patches can still interact.
If both tasks modify the same function, expect a semantic conflict even when Git merges automatically. Review combined behavior rather than relying only on textual conflict markers.
Expected observations
Each patch has the same input SHA, a distinct output SHA and a separate task record. The host working tree remains unchanged until integration. The combined result has its own verification result.
Measure elapsed wall-clock time from the whole experiment, including setup and review. Adding per-task durations and calling the total a speedup misrepresents parallel performance.
Troubleshooting
If either sandbox starts from the wrong revision, preserve the evidence and restart that comparison with the intended baseline. If resource contention makes execution slower, record the actual concurrency and host capacity. Do not hide failed or queued tasks from the comparison.
Review remote publication separately. Two sandboxes pushing the same branch can race even though their local filesystems are private.
Interview practice
Does one sandbox per task eliminate all concurrency problems?
No. It separates some local state while external services, credentials, remote repositories and host resources may remain shared. Draw those dependencies explicitly.
Why test again after merging two passing patches?
Each patch was verified against its own baseline. Their combination is a new program state with possible semantic interactions.
Completion check
Produce the task-to-sandbox map, baseline and output SHAs, combined verification and a list of remaining shared resources.
Sources and version notes
Checked 6 October 2026; current baseline: sbx v0.46.0. Use Git with sandboxes · Architecture · Share agent skills
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.