Recovering from a Coding Agent’s Bad Multi-File Edit

A coding agent changes a shared interface, rewrites its callers, updates tests, and announces success. Then the build fails, unrelated files look different, and your unfinished work is tangled into the patch. The safest recovery is not another broad instruction to fix everything. It is a controlled rollback with evidence preserved.

1. Stop the agent and freeze the workspace

Cancel active agent tasks and pause automated formatters or watchers that modify files. Stop concurrent agent sessions using the same checkout. Do not ask the agent to repair its own changes yet: another pass can obscure which edits caused the failure.

Before running destructive commands, make a private copy of the entire repository directory outside the working tree, including hidden files and untracked content. This backup may contain credentials, so keep it local and out of shared storage. Record the current commit with git rev-parse HEAD.

2. Inventory every category of change

Run git status --short, followed by git diff --stat and git diff --cached --stat. These distinguish unstaged changes from staged changes. Use git ls-files --others --exclude-standard to list untracked files; ordinary diffs do not include them.

Read both git diff and git diff --cached. If the agent created commits, inspect git log --oneline -n 10 as well. A clean working tree does not mean the unwanted edit is gone; it may already be committed.

3. Establish the last trustworthy boundary

Find the commit or checkpoint immediately before the agent started. Compare it with your current state, but do not assume every difference belongs to the agent. Your own unfinished edits may predate the session.

• Clean starting tree: The pre-agent commit is usually a reliable rollback boundary.
• Existing local edits: Use your backup, editor history, or a pre-agent patch to distinguish your work from the agent’s changes.
• No reliable boundary: Reconstruct changes file by file. Git cannot identify authorship within an uncommitted patch.

Write down the intended outcome: preserve your configuration change, remove the interface rewrite, and keep one useful test, for example. That list is your recovery specification.

4. Choose the smallest safe rollback

For uncommitted changes in a file containing no work you need to preserve, use git restore --source=CHECKPOINT --worktree -- path/to/file, replacing CHECKPOINT with the verified commit. This replaces the working-tree version but leaves staged content untouched. If unwanted edits are staged too, restore both locations with --staged --worktree only after reviewing what will be discarded.

For mixed files, use interactive restoration with git restore --patch --source=CHECKPOINT --worktree -- path/to/file. Read every hunk. If good and bad edits overlap, edit manually against the backup instead of accepting a large hunk blindly.

For an isolated bad commit already shared with others, prefer git revert COMMIT on a clean working tree. Resolve conflicts deliberately. Avoid blanket resets and git clean -fd; they can erase unrelated work or untracked files.

5. Repair dependencies as a set

A multi-file edit often changes a contract and its consumers together. Check exported types, callers, fixtures, migrations, generated artifacts, and lockfiles. Restoring only the implementation can leave tests expecting an interface that no longer exists.

Review new files separately. Remove only files you have confirmed are disposable. If the agent ran migrations or changed external services, restoring Git files will not reverse those effects; follow the relevant rollback procedure.

6. Verify behavior, not just a smaller diff

Run the narrowest failing test first, then relevant type checks, lint checks, and the broader test suite. Use the repository’s documented commands. Inspect git diff --check, both staged and unstaged diffs, and status again. Confirm that expected files remain and unrelated changes survived.

7. Restart with a bounded assignment

Save the verified recovery as a commit or checkpoint. Give the next agent a smaller task, explicit file boundaries, acceptance tests, and instructions to stop before unrelated refactors. In CodeRelay Hub workflows, switching models does not replace these safeguards: rollback boundaries belong to your repository, not the API endpoint.

Open a free workspace to try a more controlled workflow.