Understand direct workspace risk

What you will build

A review checklist for a directly shared repository, using only a synthetic project. The goal is to notice changes that become dangerous later, when a trusted host tool reads them.

Read the mechanism

Direct mode is useful for tight feedback loops: the editor and sandbox see one working tree. That convenience also means the agent can change the next command you run. A modified package script, Makefile, editor task, CI definition or project instruction can influence execution outside the sandbox after the session ends.

Review is therefore more than reading application source. Git’s ordinary diff covers tracked content, but not every relevant artifact. Untracked files require attention; ignored files and Git hooks need separate handling. Never assume a clean-looking source diff proves the workspace unchanged.

The risk is delayed execution. An apparently successful sandbox session may leave a build script that runs later on a host, CI runner or teammate’s machine. Isolation does not sanitize the code it produces.

Worked lab · a benign delayed effect

In a new synthetic Git repository, add this Makefile. Recipe indentation must be a tab:

review:
	@printf 'original review task\n'

Commit your baseline using your normal local Git identity, then create a direct shell sandbox over this repository:

sbx create --name handbook-direct shell .
sbx exec handbook-direct sh -c 'printf "\n# Added by the teaching sandbox\n" >> Makefile'
git diff -- Makefile
git status --short --untracked-files=all
git diff --name-status
git diff --check

The added comment is deliberately harmless. The lesson is that the same write capability could alter an executable recipe. Do not substitute a destructive payload to “prove” the risk.

Before running changed project commands, classify the changed files: application code, dependency metadata, execution configuration and agent instructions. Record whether the action you plan to run consumes any of them.

Expected observations

The host diff immediately shows the new comment. No copying or synchronization step is necessary. The repository remains on the host even after the sandbox is stopped.

For a review exercise, describe how you would inspect a new Git hook without executing it. Also explain why untracked or ignored files may escape a routine git diff. Do not print actual credential files into your notebook.

Troubleshooting

If a file appears only inside the guest, confirm the sandbox was not created in clone or mountless mode. If Git reports no diff, check whether the file is tracked and whether you are examining the right checkout. Avoid running git clean or resetting the repository to troubleshoot visibility.

For important work, choose a clean working tree and a dedicated branch before starting. A separate worktree can isolate direct-mode edits from your primary checkout; it still needs review.

Interview practice

Completion check

Explain why direct mode fits a trusted disposable workspace and why it requires a broader review gate for real repositories. List at least four executable configuration surfaces.

Sources and version notes

Checked 6 October 2026; current baseline: sbx v0.46.0. Security model · Isolation layers