Field entry, 7 April.
The agent fixed the right bug in the wrong tree, which is one of those sentences that sounds like a joke until it is your afternoon. There is no elegant way to soften it because the problem itself is brutally simple: the issue was real, the diagnosis was useful, the code change made sense, the test was appropriate, and all of it took place in diminuendo-otel-investigation, which was not the live working tree.
This is the sort of mistake that sounds funny once nobody is bleeding. It is also one of the cleanest examples I have seen of an AI-agent failure mode that is not about intelligence, taste, or model capability. It is about location, the oldest problem in travel writing and apparently still alive in software.
For humans, the question “where am I?” has a lot of ambient answers: the editor window, the terminal prompt, the branch name in the status bar, the fact that you remember why you opened this folder, and the vague shame of having too many tabs while still knowing which one contains the work that matters.
Agents do not have that kind of embodied workspace memory. They have context, commands, paths, and whatever discipline the toolchain enforces. If the discipline is weak, they can be extremely competent in the wrong place.
In this session, the underlying bug involved local execution and path normalization. A command tried to run something like /workspace/solution.ts on a Mac/local runtime where that sandbox-style path did not map to the actual local workspace root. The fix was sensible: rewrite sandbox-style absolute paths such as /workspace/..., /project/..., and /root/project/... onto the real local workspace before execution, matching the behavior already used by file writes.
That was a good fix, but applied to the wrong tree it became a liability, like delivering excellent medicine to the wrong house.
The recovery was the important part. The agent confirmed the wrong-tree diff was limited to the two edits it had introduced. It reverted those changes there. It applied the fix in the live tree. It ran the focused tests in the correct location. It verified the wrong subtree was clean again.
This is exactly the kind of incident that should become a rule: before editing, prove the workspace. Not once at the beginning of the day, and not vaguely through the current working directory in the prompt, but when the risk is real: show the repo root, show the branch, show whether there are sibling worktrees with similar names, show whether the target file exists in multiple places, and if a project has investigation branches, generated forks, or parallel agent worktrees, assume location is a possible failure mode.
The reason this matters is that agents multiply work.
A human in the wrong worktree might make one mistaken edit, notice something feels off, and stop. An agent can make the mistaken edit, add a test, run the test, summarize the victory, and move on with a cheerful little bow. The confidence is earned locally and false globally.
That is the dangerous part: every local signal can be green. The tests passed in the wrong tree, the diff was coherent in the wrong tree, the explanation was accurate for the wrong tree, and the product was still unfixed.
This is why workspace identity belongs in the same category as permissions and destructive commands. It is not merely environmental context. It is a safety property.
The fix is partly tooling: better prompts, stronger branch displays, guardrails that warn when similar worktrees exist, commands that require explicit target roots for edits, and agents that include cwd and git status before modifying files in multi-worktree repos. But it is also a habit: when something feels off, stop; when the user asks “why are you in that tree?”, do not defend the path, inspect it; and when the agent has edited the wrong place, do not stack more cleverness on top, but revert only what it touched, move to the right tree, and reapply carefully.
That last part matters too. Recovery should be surgical. A wrong-worktree incident is already a trust injury; broad cleanup only makes it worse. The agent needs to show that it knows which fingerprints are its own.
I suspect this class of bug is going to become more common, not less. Agentic development encourages parallelism: multiple agents, multiple worktrees, experiments, review branches, reproduction folders, generated implementations. That is good. It is also a geography problem.
As the field expands, the map has to get better.
Field note
I want future coding agents to have a pre-edit reflex that feels almost boring: repository, branch, worktree, target path, dirty state, similar sibling paths, and only then the patch.
Not because the agent is untrustworthy, but because fast work in the wrong place is worse than slow work in the right one.