Rewinding a coding agent to an earlier turn

An agent that went wrong on turn six did not necessarily go wrong on turn one. brindle snapshots a worker's worktree after every turn that changed files, so you can go back to the good state and continue from there.

Long agent sessions drift. The first few turns fix the problem, and then a later turn rewrites something that was fine, or chases a wrong idea through three files. You can tell the agent to undo it, but an agent undoing its own work often adds more changes on top. A cleaner option is to restore the files exactly as they were and start a fresh session from that point with the knowledge of what went wrong.

See the turns

brindle records a snapshot of a worker's worktree after each turn that changed files. List them for an agent with:

brindle ls
brindle agent turns d2010b34

brindle ls gives the agent id. brindle agent turns lists the turns that were snapshotted, numbered from 1. Turns that changed nothing are not snapshotted, so the numbers are the turns that matter. Supervisors can do the same through the agent_turns tool, which is useful when the supervisor notices that a worker's branch has gone sideways.

Rewind to turn N

Pick the last turn whose result you want to keep and rewind to it:

brindle agent rewind d2010b34 --to 3 --note "Keep the retry in the client; do not touch the session code"

brindle puts the worktree back as it was after turn 3 and starts a fresh session there. The new session is briefed on the task, on turns 1 through 3 and on your note, so it knows what has been done and what you want different. It does not inherit the conversation that led to the bad turns, which is the point. Your note is the place to say what you learned: the approach that failed, the file to leave alone, the test that now defines done.

Two options help when the model is part of the problem. --profile restarts the worker on another profile, for example moving a hard task from a light profile to a heavy one. Rewind works for any provider, Codex included, so you can restart a Claude worker as a Codex one or the other way round. Supervisors have the matching rewind_agent tool, and the supervisor can use it to recover a worker without asking you.

Before you let the new session continue, look at brindle diff for the branch and check that the state is what you expect.

When to rewind and when to message

Rewind is the heavy tool. If an agent is on the right track and needs a small correction, send a message with brindle send and let it keep its context. Rewind when:

• the agent has made changes that you would rather not review at all, and a message to revert them would only add more diff;
• it is stuck in a loop of fixes that make a failing check worse;
• a wrong assumption early on shaped everything after it, and a fresh session with the right assumption is cheaper than arguing the old one out of the conversation;
• you want to try a different profile or provider on the same starting point.

Parallel branches and conflicts

Rewinding fits naturally with parallel work, where the other source of trouble is two branches changing the same file. Files that a task expects to touch are a guess when the task is declared. What a branch actually changed is the truth, so brindle compares the files that each running branch has changed, committed or not, at the end of each worker turn. When two branches touch the same file it tells the supervisor once per pair, while there is still time to have one wait for the other, or to rewind one of them.

When several approved branches are ready at once, brindle merges the one whose hunks overlap the others' least first. It then brings each remaining branch up to date with the new tip by merging the base into it, so its approval carries over, and merges it in turn. A conflict then belongs to one branch and not to the whole pile. That branch goes back to its own worker with the conflicting files to resolve, or to a light worker started in its worktree if the original has finished. Its next report starts a fresh review, and the checks run again on the resolved commit before it merges. Automatic resolution never skips review or checks.

Keep some conflicts for yourself

Some files should never be resolved by an agent in a hurry: migrations, lockfiles, generated code. List them in .brindle/config.json:

{"protected_paths": ["migrations/", "*.lock"]}

A conflict in a protected path is never handed to a worker. The branch waits, and the supervisor reports it to you as needing your decision. With brindle Team, an organization can set protected paths in its policy so they apply to every repository.

Where to go next

Try it on a practice repository first: run brindle demo, and while workers are running use brindle agent turns on one of them to see the snapshots. The autopilot docs cover the review-and-merge pipeline that conflict-aware merging belongs to, and the guide to parallel agents in git worktrees explains why each worker has its own branch in the first place. For the commands themselves, see the command reference.

curl -fsSL pawdelta.com/brindle/install | sh