The agent fixed it in another worktree and tested the wrong checkout

You asked the agent to patch the failing export on a feature branch. It opened a sibling worktree, edited the file there, ran the suite from its shell, and reported green with a clean diff. You merge the target branch. The bug still happens. The commit landed in the worktree nobody merged, and the green run executed against the primary checkout, where nothing had changed.

This failure mode hides behind a genuine signal: the tests did pass. The mismatch is between where the agent edited and where the agent measured, and nothing in the report connects the two. A long-lived agent that moves between directories, or a setup that spawns parallel worktrees to avoid stepping on your files, makes the divergence easy to produce and hard to notice.

The summary quotes passing tests and a tidy diff, but it never names the working directory, the branch, or the commit SHA those tests ran on. Reviewing the primary checkout shows a clean tree, so the green feels confirmed rather than accidental.

Why a green run on the wrong checkout reads as fixed

The shell's directory and the editor's file can diverge. The agent edits a file under a sibling path while its terminal stays anchored to the primary checkout, so the test process reads unmodified code even as the changed file exists somewhere else on disk.

Green only proves the directory it ran in. A passing suite says that specific checkout clears the checks. It says nothing about whether the edited file lives in that same checkout, or whether that checkout is the branch under review.

Parallel worktrees make the two states look interchangeable. Several directories share one repository but hold different branches, so an edit in one and a test in another are physically separate yet easy to describe as the same task.

The report quotes tests, not the context. A summary that says 'suite passes' omits the pwd, branch, and HEAD SHA, so the reviewer compares green to green and never checks whether the measured tree contained the change.

The reviewed branch is clean, which looks like evidence. When the branch you inspect has no diff because the edit is elsewhere, an empty status reads as 'nothing changed,' not as 'the change is missing here.'

What it looks like in the output

Edits live under a sibling path. File operations reference a secondary worktree directory while the test commands report the primary path, and the two never reconcile in the trace.

The reviewed branch shows the file untouched. You ask for the diff on the target branch and the claimed file has no change, even though the agent described editing it.

Tests pass but the file's mtime and diff belong elsewhere. The modified file exists in another worktree; the suite ran before it could be seen.

A fresh agent session cannot reproduce the fix. Starting clean on the target branch reproduces the bug, because the patch was never committed to that branch.

The summary omits branch and SHA. It lists passing test names but never states which commit or directory produced them, so there is nothing to trace back to the actual edit.

The gate: bind every edit to the checkout it ran in

Print directory, branch, and HEAD before and after. Have the agent emit pwd, git branch, and the short SHA around each test run, then compare that tree to the tree holding the edited file. A gap between the two is the whole bug.

Verify the changed file appears in the reviewed diff. The patch must be visible on the target branch, not merely present somewhere on disk. A clean target branch with an edit in a sibling worktree fails this check.

Re-run the suite from the exact directory holding the edit. Green produced elsewhere is not evidence for this checkout. Run the tests where the change lives, then evaluate.

Require the passing commit SHA before accepting done. When worktrees run in parallel, name the SHA the tests cleared and confirm it sits on the branch destined for merge.

Close sibling worktrees the agent created. Tear down temporary directories after use so a stale checkout cannot be rerun weeks later and mistaken for the current state.

Before you accept green across a parallel checkout

1. Did the tests run in the same directory that holds the edited file, rather than the primary or a stale worktree?
2. Does the claimed change actually appear in the diff of the branch under review?
3. Did the report name the branch, working directory, and commit SHA the suite passed on?
4. Can a fresh session on the target branch reproduce the fix, or does the bug still show up there?

A passing suite after an edit is not a fix until the edit and the measurement occupy the same checkout. Bind green to the branch it ran on, require the SHA, and treat a clean target branch with the patch elsewhere as a missed ship, not a clean result.