Letting the agent use git, within limits

Agents run git now

Claude Code, Cursor’s agent mode, Copilot’s agent and the terminal tools all run shell commands, and git commands are shell commands. Left to themselves they will stage, commit, stash, reset and occasionally push. Replit, Lovable and Bolt commit to their own checkpoint systems, which is a different thing but raises the same question: what is the tool allowed to do to your history?

The answer belongs in the rules file from the first block, in plain words the tool reads every session.

The four to forbid

Git rules:
- Commit only when I ask. Never push.
- Never run: git push --force, git reset --hard, git checkout . / git restore .,
  git stash, git clean, or any command with --no-verify.
- Never touch files under migrations/ without asking.
- Before committing, show me git diff --staged and wait.

The mechanism behind the ban is worth understanding, because the agent is not being careless. It has a goal (a passing build, a clean tree so it can switch branch, a diff that shows only its work) and git checkout . is the shortest path to that goal. Your uncommitted changes from this morning are, to the agent, noise between it and a clean state. It removes them the way it would remove a stray console.log. Nothing in its summary will say “and I deleted your work”, because from its point of view it tidied.

git stash is on the list for a softer version of the same reason: work parked by an agent is work you do not know is parked.

The session ritual

Commit before the agent starts. Not because the work is finished, but so that the boundary is exact: everything in git diff afterwards is what the agent did and nothing else. This is the version of “commit when it works” for agent sessions, and it costs ten seconds.

After it finishes, three commands in order:

git status          # which files, including ones you did not expect
git diff            # what changed, read as in the reading block
git diff --stat     # the shape: forty lines in one file, or forty files

Then commit yourself, with a message that says what is now true. If the agent wrote the message, check it against the diff. Agents routinely describe intentions rather than results (“Add tests for cancellation” over a diff containing no test) and a log full of those is a log you cannot trust when you are searching it at midnight.

The hook the agent will ask to skip

A pre-commit hook is a script git runs before accepting a commit. The common setup runs the type checker and the linter and refuses the commit if either fails; tools like husky and lint-staged set it up, or a plain executable file at .git/hooks/pre-commit does the same with no dependency.

An agent that hits a failing hook will propose git commit --no-verify. That flag exists for emergencies and the agent is not in one. The hook has found a problem; the answer is to fix the problem. Put --no-verify in the forbidden list and the conversation does not happen.

Granularity

A long agent session produces one enormous diff, and one enormous diff produces one enormous commit, which is exactly the commit that bisecting cannot see inside. Ask for a commit at each checkable step from the slicing lesson: “Commit after the migration, after the API route, after the screen.” Three commits, each a working state, each revertable on its own.

Files the agent leaves behind

Scratch scripts, screenshots it took to check the screen, .claude/ or .cursor/ folders, log files, the test.txt it wrote to check file access. Add these to .gitignore as you notice them, and read git status for untracked files before every commit. A repository slowly filling with an agent’s droppings is a repository nobody wants to read.

The co-author line

Most tools append a Co-Authored-By: line naming themselves to commits they write. Keep it. It is accurate, it costs nothing, and the person who reads this history in a year (a collaborator, a developer you hire, you) will want to know which commits were machine-written when deciding how carefully to read them.