# 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.

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

::: warning Not the same as `make sandbox`
This is unrelated to the [sandbox](/guide/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

::: danger 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](/harness/circuit-breaker) streak, the
[session timeline](/harness/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](/harness/circuit-breaker) — the streak this feeds
- [Enforcement Doctrine](/harness/overview) — why gates read evidence, not narration