What you will build
A change produced inside a private clone and fetched back as a reviewable Git object. Clone mode is an integrity boundary for the host working tree, not a promise that the agent cannot see host repository secrets.
- Host repository read-only
- Private clone in guest
- Agent creates commit
- Host fetches for review
Conceptual flow. Follow the lesson for prerequisites, exact commands and verification limits.
Read the mechanism
With --clone, the agent edits a separate repository inside the sandbox. The source repository is still mounted read-only at /run/sandbox/source. Ignored and untracked files present in that source can remain readable through the source mount. A private .env does not become safe merely because Git ignores it.
Clone mode is selected at creation. It follows the host’s checked-out ref and does not create a feature branch for you. Current docs reject clone creation from a linked Git worktree; use the main repository checkout for this mode. Extra workspaces are direct mounts, so evaluate those separately.
The host receives a sandbox-<name> remote. Fetching from it retrieves committed work; fetching is not merging and does not execute the fetched code. That separation gives a useful review gate.
Worked lab · produce one reviewable commit
Use a clean synthetic repository with a baseline commit. Before creation, check for untracked and ignored material and remove sensitive material from the teaching source by preparing a separate sanitized copy.
git status --short --untracked-files=all
sbx create --clone --name handbook-clone shell .
sbx exec handbook-clone git status --short
sbx exec handbook-clone sh -c 'printf "private clone change\n" > lesson.txt'
sbx exec handbook-clone git add lesson.txt
sbx exec handbook-clone git -c user.name=Handbook -c user.email=handbook@example.invalid commit -m "Add teaching note"
git status --short
git remote -v
git fetch sandbox-handbook-clone
git log --oneline --all -5Inspect the fetched commit and its diff by the SHA printed in your log. Do not paste an invented SHA from a tutorial. If you want to integrate it, first create a host review branch and use your normal reviewed merge or cherry-pick workflow.
Expected observations
The host working tree should not contain the new lesson.txt merely because the agent wrote it. The private commit becomes available after fetch. Your host remains unchanged until you explicitly integrate the commit.
Uncommitted guest edits are not carried by a Git fetch. Commit intended work or export a patch before removal. Removing the sandbox deletes its private clone and removes the sandbox remote from the host repository.
Troubleshooting
If fetch contains no change, verify that the guest actually committed it and inspect its branch. If clone creation fails from a worktree, use the documented main-checkout path or choose a separate direct-mode worktree. Do not rewrite Git metadata to bypass the limitation.
Interview practice
Why is clone mode not secret isolation?
The read-only source mount can expose files that Git did not clone, including ignored and untracked content. Read-only blocks writes, not reads or downstream disclosure.
Why fetch before merge?
Fetch makes objects available for inspection without updating the current working tree. A separate integration step allows review of code, dependencies and executable configuration.
Completion check
Show the private commit, its fetched SHA and the unchanged host working tree. Explain how you would preserve uncommitted work and why the source must still be sanitized.
Sources and version notes
Checked 6 October 2026; current baseline: sbx v0.46.0. Use Git with sandboxes · Usage
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.