Simon Willison’s guide on using Git with coding agents lands at a good time. The agentic tooling landscape has matured enough that teams are moving past the novelty phase and into actual workflow design, and Git sits at the center of almost every hard question: how do you roll back a bad agent session, how do you run multiple agents without them stepping on each other, and how do you keep your commit history meaningful when an agent might produce twenty commits in ten minutes.
The core principle is straightforward: an agent that can edit files freely is only as safe as your ability to undo what it did. Git is that undo mechanism. But making it work well requires deliberate structure, not just occasional git stash.
The Auto-Commit Divide
The most fundamental design split in coding agent tooling is whether the agent commits automatically after every change or leaves committing to the developer.
Aider sits firmly in the auto-commit camp. By default, Aider commits every change it makes with a generated message prefixed aider:, so your history ends up with entries like aider: refactor authentication to use JWT refresh tokens. The working tree stays clean between operations, which means you can always run git diff HEAD to see exactly what Aider’s last action was. You can also undo the last Aider commit with aider --undo. Paul Gauthier’s reasoning for this default is that a clean working tree is a prerequisite for the agent being able to reason clearly about the current state of the repo. If you run Aider on a dirty tree, it warns you.
Claude Code takes the opposite approach. It edits files, runs tests, reads git log and git diff for context, but does not commit on its own unless you explicitly instruct it to. The agent is aware of git state but treats committing as a human action. If you want automatic commits, you encode that in the CLAUDE.md file at the repo root:
## Git Policy
After each discrete logical change:
1. Run the test suite
2. Commit with: `git commit -m "<type>: <what> [agent]"`
Valid types: feat, fix, refactor, test, docs, chore
3. Never amend published commits, force push, or rebase shared branchesOpenAI’s Codex CLI defaults to an even more conservative stance: in sandbox mode it will not write to the filesystem at all, and in --full-auto mode it writes files but does not commit. Changes are reviewed before they enter version control.
Neither approach is strictly better. Auto-commit gives you a fine-grained, automatically created rollback history and keeps the working tree clean. Manual commit gives you control over when changes become part of the record, which matters when an agent might write several exploratory attempts before landing on a correct solution. The right choice depends on how much you trust the agent’s output and how important commit hygiene is in your workflow.
Git Worktrees: The Underused Tool
The most practically valuable pattern for anyone running multiple agent sessions is git worktree, a native git feature available since git 2.5 (2015) that lets you check out multiple branches simultaneously into separate directories, all sharing a single .git object store.
Without worktrees, running two agent sessions on the same repo is a coordination problem. Both agents might edit the same file, both might need to read git state that the other is in the middle of modifying, and the HEAD pointer is a single shared resource. The naive solution of cloning the repo twice wastes disk space and breaks the shared object store, meaning neither agent benefits from the other’s committed objects.
With worktrees, you set up isolated working directories per task:
# Start from your main repo directory
git worktree add ../myrepo-agent-auth agent/fix-auth
git worktree add ../myrepo-agent-tests agent/add-tests
# Each gets its own branch and working directory
cd ../myrepo-agent-auth && claude "fix the token expiry bug in src/auth.ts"
cd ../myrepo-agent-tests && claude "add unit tests for the auth module"
# When done, clean up
git worktree remove ../myrepo-agent-auth
git worktree remove ../myrepo-agent-testsEach worktree has its own index and HEAD, so agents commit to their own branches without interfering. They share packed objects, so if both agents are working with the same large files, there is no duplication. And git worktree list gives you a clear view of what is currently checked out where.
This pattern also works well for the common case of a human working on one branch while an agent works on a separate branch for a parallel task. You do not need to switch branches or stash your current work.
Branch Protection Is the Real Safety Layer
Giving an agent push access to a repository without branch protection in place is a significant risk. An agent can push to main if its credentials allow it, and if it has been instructed to “clean up the commits” it might attempt git rebase or git commit --amend on shared history.
The mitigations are mostly standard GitHub workflow hygiene applied specifically for agent access:
- Branch protection on
main: require PRs and at least one human review before merging - Required status checks: CI must pass before any branch can merge, including agent-generated branches
- Restrict force push: block
--forceat the repository level or via branch rulesets CODEOWNERS: require review from code owners on agent-generated PRs that touch sensitive paths- Draft PR convention: agents should open draft PRs rather than ready-to-merge PRs, signaling that human review is required
On the local side, pre-commit hooks serve as a checkpoint that runs even on agent-triggered commits:
# .git/hooks/pre-commit
#!/bin/bash
git secrets --scan # block accidental secret commits
npx tsc --noEmit # type check before committing
npm run lint --silent # lintingThis matters because auto-committing agents will commit whatever state the files are in. A pre-commit hook that runs your type checker or linter catches broken commits before they land in history, regardless of whether a human or an agent triggered the commit.
Commit History Hygiene
Agent-generated commit history has a noise problem. An agent working on a medium-complexity task might produce a dozen commits, several of which are false starts, over-engineered approaches, or test-only changes that get immediately reverted. That history is useful for rollback during the session but pollutes the permanent record.
A few patterns help here. Prefixing agent commits (Aider’s aider: convention, or a team-defined [agent] suffix) makes them filterable with git log --grep. This lets you audit agent work separately from human work when debugging or doing code archaeology later.
For merging agent branches, git merge --squash collapses all agent commits into a single staged changeset that you then commit with a clean message. This discards the intermediate history but preserves the net change. An alternative is git rebase -i to squash and fixup before merging, which retains a curated subset of commits.
When an agent produces many small commits and you want to keep them but need to find a regression, git bisect works well because agents tend to commit at logical checkpoints:
git bisect start
git bisect bad HEAD
git bisect good main
git bisect run npm testAider’s commit-per-change discipline is especially friendly to this workflow. Each aider: commit represents one logical operation, so bisect can often identify the exact agent action that introduced a bug.
The Checkpoint Habit
Regardless of which agent you use or how it handles commits, the single most important habit is committing or stashing before every agent session. The cost is three seconds. The benefit is a clean rollback point if the agent takes the code in a direction you do not want:
git add -A && git commit -m "wip: checkpoint before agent session"
# ... run agent ...
git diff HEAD~1 # review what changedReviewing diffs rather than individual files after an agent session is also worth building into your workflow. git diff gives you the precise surface area of what the agent touched, which is a more efficient review format than opening each changed file in an editor.
Willison’s guide frames git as the primary safety mechanism for agentic engineering, and that framing holds up. The specific tool choices matter less than the structural habits: isolated branches, clean pre-session state, branch protection on shared refs, and a consistent commit prefix that makes agent work identifiable in history. These are all standard git hygiene practices that turn out to be especially important when the entity making changes can operate much faster than a human and does not always catch its own mistakes.