Git with an agent: commit, branch and assisted code review

The agent already sees your git state from the first turn: current branch, modified files and recent commits enter as their own block at the end of the system prompt. The part that changes from setup to setup is what it does without asking.

And there is a documented list of operations auto mode refuses on its own, with no rule from you at all. Knowing that list changes what is worth delegating.

In auto mode, a second model reviews the actions in your place. For git, it ships with a refusal list covering what hurts most often.

Discarding uncommitted work. Six commands the classifier assumes would throw changes away: git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop and git stash clear.

Rewriting shared history. Force push gets blocked. So does git commit --amend, in two cases: when the commit at HEAD was not created in this session, and when it has already gone to the remote. The exception is rewriting only the message of a commit the agent itself made during the session, with nothing new staged.

One trust detail is worth knowing. The classifier trusts your working directory and the remotes that were already configured when the session opened. A remote added or repointed mid-session, with git remote add or git remote set-url, inherits none of that trust. It is a protection against the case where someone talks the agent into pointing your code somewhere else.

That is default behavior, not a permission rule. For a guarantee that depends on no classifier, the route is a deny rule, covered in permissions and auto mode:

{
  "permissions": {
    "deny": ["Bash(git push --force *)", "Bash(git reset --hard *)"],
    "ask": ["Bash(git push *)", "Bash(gh pr merge *)"]
  }
}

Worth remembering that read-only git commands, such as git status, git diff and git log, already run without a prompt in every mode. Clearing them in the configuration is noise.

Generating the commit message is the highest-return delegation in git, because the agent sees the whole diff and you skip rereading what you wrote a moment ago.

The part I keep is the shape of the commits. Deciding what goes into each commit is a decision about the project's history, and the agent tends to group by file instead of by intent. The pattern that works: you git add whatever forms one unit, and ask for the message of what sits in the stage.

Two things help more than any prompt:

A convention in CLAUDE.md. Message format, language, type prefix, issue reference. It is the kind of rule that has to hold every time, which is why it lives there and not in a skill. The anatomy of the file covers the rest.

A hook instead of an instruction, when you need a guarantee. "Run the tests before committing" in CLAUDE.md is a request. A PreToolUse hook matching Bash and exiting with code 2 is a real block.

Here sits the feature that most changes the flow for anyone running more than one task at a time. A worktree is a separate working directory, with its own files and branch, sharing the history of the same repository.

claude --worktree feature-auth

That creates the checkout in .claude/worktrees/feature-auth/, on the new branch worktree-feature-auth, and starts the session inside it. Running the command again with another name, in another terminal, gives you a second session that touches none of the first one's files. Omit the name and Claude Code generates one, along the lines of bright-running-fox.

Three adjustments worth making on day one.

Ignore the directory. Put .claude/worktrees/ in .gitignore, or the worktree contents show up as untracked files in the main checkout.

Bring the files git ignores. A worktree is a clean checkout, so .env and its kin are not there. A .worktreeinclude file at the project root, with .gitignore syntax, solves it:

.env
.env.local
config/secrets.json

The rule is strict and good: it copies a file only when it matches the pattern and git ignores it, so nothing tracked gets duplicated.

Choose where the branch is born. By default the worktree starts from the remote's default branch, which gives you a clean tree. With worktree.baseRef set to "head", it starts from your local HEAD and carries the commits you have not pushed. Useful when the isolated work needs to continue from where you are.

Starting from a pull request also works, which shortens reviewing someone else's code by a lot:

claude --worktree "#1234"

The quotes keep the shell from treating # as the start of a comment.

The isolation is enforced, not suggested

Inside a worktree, Claude Code blocks four classes of call that would escape into the main checkout:

You cannot turn the last one off, and it surprises people the most: a heredoc Claude Code cannot trace gets refused even with no git anywhere on the line. The way out is rewriting it as separate commands, and the error message says so.

The same set of checks applies to every subagent created from the isolated session. And a subagent can get a worktree of its own, with isolation: worktree in its frontmatter, which is how mechanical refactoring runs in parallel without conflict.

What the worktree shares

Three things cross the boundary, and all three are convenient:

• The .git directory, so git commit works from inside the worktree, even with the sandbox on.
• Project-scoped plugins, which need no reinstall per worktree.
• Permission approvals: a "yes, and stop asking" given inside the worktree gets saved to the main checkout's settings.local.json, holds across every worktree, and survives that one's removal.

On exiting an interactive session, Claude Code checks whether the worktree holds any work. Clean and unnamed, it removes it on its own. Named, or with changes and commits inside, it asks first.

The local /code-review requires installing nothing and depends on no plan. It reviews the commits on your branch ahead of upstream plus whatever sits in the working directory:

/code-review                      # current branch + uncommitted
/code-review main...my-feature    # a range of refs
/code-review 1234                 # a pull request
/code-review --fix                # applies the findings
/code-review --comment            # posts as an inline comment on the PR

It runs as a forked subagent in the background, with its own context window, so the review never fills your conversation. The findings arrive when it finishes, which fits the cost argument from the measurement across 48 thousand turns and the criteria for when to delegate.

The effort level changes the nature of the result, and the docs say so. At low and medium the review reports only what it is most confident about, with fewer false positives. From high up it widens coverage and can include things it is less sure of. The level stays remembered between sessions until you type another.

The managed service also exists, reviewing pull requests on GitHub and posting inline comments. Three things are worth knowing before pitching it to the team: it is in research preview, only Team and Enterprise plans get it, and it costs on average US$15 to 25 per review, charged in usage credits and outside the plan's allowance. The trigger you choose multiplies that: reviewing on every push costs per push.

One project choice avoids friction: the check run always concludes as neutral, so the review never blocks a merge through a branch protection rule. To gate a merge, you have to read the severity counts from the check output in your own CI.

The managed service reads two files from the repository, with different weights.

CLAUDE.md enters as project context, and a new violation of it becomes a nit finding. It works both ways: if your PR changes the code such that a statement in CLAUDE.md goes stale, that gets flagged too.

REVIEW.md, at the repository root, is review-only instruction, handed straight to the agents that find, verify and classify the findings. It is where the real problem of automated review gets solved, and that problem is volume:

# Review instructions

## What counts as Important here

Reserve Important for what breaks behavior, leaks data or
prevents rollback. Style and naming are Nit at most.

## Cap the nits

Five Nits per review, maximum. If you found more, say "N more
similar items" in the summary.

## Do not report

- What CI already covers: lint, formatting, type errors
- Generated files in `src/gen/` and any `*.lock`

## Always check

- A new API route has an integration test
- Logs include no email, user ID or request body

Two of its rules deserve attention, because they solve predictable irritations. The evidence bar demands proof before a kind of finding gets posted, something like "a claim about behavior needs a file:line citation, not an inference from the name". And convergence between reviews avoids the seventh round over style: "after the first review, report only Important findings".

One asymmetry confuses people: the local /code-review follows your CLAUDE.md, and does not read REVIEW.md. The file holds for the managed service.

The file does not expand the @ import syntax, so referencing another document fails. The rules have to live inside it. And length has a cost: a long REVIEW.md dilutes the rules that matter.

One confusion costs lost work. Claude Code takes a snapshot of the file before editing, and Esc twice rewinds to an earlier state. That is useful, it is independent of git, and it has limits that need to be clear:

And the case that catches experienced people: a background review that applied --fix wrote outside your session's checkpoints. /rewind undoes none of that. To revert, it is git.

The practical reading is simple: a checkpoint is the session's safety net, git is the project's safety net. Committing before sending the agent to do something broad remains the habit that saves the most, and it is the same reasoning as the guide to Claude Code in production. For the flow all the way to the server, deploying Next.js on GitHub and Hostinger closes the chain.

Can the agent erase my uncommitted work?

In auto mode, the six commands that discard changes (git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop and git stash clear) hit a classifier block by default. That is behavior, not a contractual guarantee: for a guarantee, write a deny rule, which gets evaluated before any permission.

What is the difference between --worktree and creating the branch by hand?

The worktree gives you a separate directory, so two sessions edit different files at the same time without conflict. Switching branches in the same directory changes the files under a session that is working. Claude Code also applies four checks that stop commands from escaping the worktree into the main checkout.

Does the local /code-review need the GitHub app?

No. It reviews the diff in the terminal, installs nothing, and works on any plan. The GitHub app is for the managed service, which comments on pull requests, sits in research preview and reaches only Team and Enterprise plans.

Why did /rewind not undo the review's fixes?

Because the review runs in the background and applies its --fix edits outside your session's checkpoints. It reaches them again once the review runs in the foreground, editing during your turn. For the background case, use git.

• Anthropic — Claude Code Docs: Code Review. Accessed 21 August 2026.
• Anthropic — Claude Code Docs: Run parallel sessions with worktrees. Accessed 21 August 2026.
• Anthropic — Claude Code Docs: Choose a permission mode. Accessed 20 August 2026.
• Anthropic — Claude Code Docs: How Claude Code works. Accessed 20 August 2026.
• Anthropic — Claude Code Docs: Configure permissions. Accessed 20 August 2026.

Verified on 21 August 2026.

Review trigger: revisit when (a) the list of git commands the classifier blocks changes, (b) managed Code Review leaves research preview or reaches other plans, or (c) the local /code-review starts reading REVIEW.md.