Isolated Verification

forge verify --isolated runs your project's tests and build against an ephemeral copy of the repository, so code the agent just wrote cannot corrupt your working tree — or the uncommitted work sitting in it.

forge verify --isolated
# isolated: running verification in an ephemeral copy (working tree untouched)
# Verify: … Verdict: PASS

Not the same as make sandbox

This is unrelated to the sandbox, which is forge's end-to-end demo harness. This page is about isolating execution.

What the copy contains

A faithful snapshot of your current working state, not just the last commit:

Included	How
Committed files	a detached git worktree at HEAD
Uncommitted changes to tracked files	git diff HEAD replayed with git apply
Untracked files	git ls-files --others --exclude-standard
Ignored files (node_modules/, build output)	excluded

If the patch fails to apply, the command errors rather than continuing — verifying code that isn't what you actually have is worse than not verifying. Isolation requires a git repository; in a non-git directory the command refuses instead of silently running against your real tree.

What it actually isolates — and what it doesn't

Read this before trusting it

This isolates the filesystem working tree. It does not isolate processes, the network, /tmp, or $HOME. It is a safety net against a test or build accidentally corrupting your work — it is not a security boundary against hostile code.

One further limit worth knowing: because the copy is a git worktree, its .git points into the source repository's git directory. Checked-out files are isolated; git metadata is still reachable. A test that writes files is contained; a test that runs git commands is not fully.

If you need real containment — untrusted code, network denial, process limits — you want a container or VM. Forge does not pretend to provide that.

Where state is written

Verification reads from the copy, but the harness state stays on the real repository: the circuit-breaker streak, the session timeline event, and --change reporting are all keyed to your actual repo.

That split is deliberate. The copy is discarded when the command returns, so a breaker streak recorded there would vanish and never reach its threshold — the gate would silently never fire.

The property, demonstrated

A command run inside the copy that deletes a tracked file and creates a new one:

COPY   tracked.txt   removed
SOURCE tracked.txt   still present (with its uncommitted edit)
SOURCE created.txt   never appeared

That is the whole point: destructive work lands in something you were going to throw away.

See also

• Verify circuit-breaker — the streak this feeds
• Enforcement Doctrine — why gates read evidence, not narration