Git Workflows with Claude Code and Codex

Git is the undo button for a coding agent. Every rule on this page exists to keep that button working: small commits you can revert, branches you can throw away, and a short list of commands the agent never runs on its own.

Both Claude Code and Codex expect to work inside a Git repository. Codex even picks its default permissions based on whether the folder uses version control. The docs explain how each piece works. This page turns those pieces into a routine and fills in the parts the docs leave to you.

Checkpoint before every task

Start each task with no uncommitted changes in the folder. Codex's getting-started page puts it plainly: create Git checkpoints before and after a task so you can revert changes (Codex CLI docs). The minimum version is two commands:

git status --short   # should print nothing
git switch -c agent/saved-searches

A clean start means git diff after the task shows only the agent's work. A dedicated branch means git switch main && git branch -D agent/saved-searches throws the whole attempt away if it goes wrong.

Claude Code also has its own checkpoints. Every prompt creates one, and /rewind (or double Escape) restores the code, the conversation, or both.

They have a limit, and the docs say so. Checkpoints only track changes made through Claude's file-editing tools, not changes from shell commands, and they are not a replacement for git (best practices). Use them for "try that again differently". Use git for anything you'd want back tomorrow.

Commit small and often

One task, one commit. If you split the work into small tasks, as in the plan mode guide, commit after each one passes its check. The next task starts from a clean slate, and you have a named point to go back to.

You can let the agent do the committing. Anthropic's quickstart shows prompts like "commit my changes with a descriptive message" (quickstart). What you get depends on what you told it. Put your commit rules in CLAUDE.md or AGENTS.md, the instruction files the agent reads at the start of every session. A rule you have to retype each session is a rule you'll forget.

Commit message discipline

With no rules, an agent's commit message can end up as a list of the files it touched. git show --stat already gives you that. A useful message says what changed and why, in words someone can search for a year from now. These rules are worth putting in the instruction file:

## Git
- One logical change per commit. Don't mix a fix with a refactor.
- Subject line: imperative, under 72 characters, says what changed.
- Body: why the change was needed, and anything a reviewer should check.
- Don't list files; git already records them.
- No debug code, console.log, or commented-out blocks in a commit.
- Never commit .env files or anything that looks like a key.
- Commit author: use the repo's configured git identity. Never change git config.

This site's own AGENTS.md has a version of most of these, including the author identity rule and one logical change per commit.

Claude Code signs its work by default. It adds a Co-Authored-By line at the end of each commit message and a line in pull request descriptions. You can change or remove both with the attribution setting. The older includeCoAuthoredBy setting still works, but it's deprecated, so new setups should use attribution (settings reference).

Your own attribution instructions in CLAUDE.md win over those default lines, unless the defaults are set in managed settings. Whatever you choose, choose it on purpose. That line is a permanent record of who wrote the code.

How each tool handles commits

The two tools draw the line in different places:

• Codex. Codex works inside a sandbox, a fenced-off area with limited permissions. In the default workspace-write sandbox, the .git folder, where git keeps your history, is read-only, along with .codex and .agents (approvals and security). Codex can edit your files freely in Auto, but anything that writes to .git, such as a commit, has to step outside the sandbox. Under the on-request approval policy, expect Codex to ask you first.
• Claude Code. It depends on the permission mode. In Manual mode it asks before running commands. In auto mode a separate classifier checks each action before it runs, and its default block list includes force pushes, git reset --hard, git checkout -- ., git restore ., git clean -fd, dropping or clearing stashes, and amending a commit that wasn't created in this session or has already been pushed (permission modes).

Neither default is a policy you wrote. If a git action matters to you, write it into the instruction file. In Claude Code you can also add a permission rule, which blocks the action in every mode.

Branches and pull requests

For anything beyond a scratch repo, have the agent work on a branch and land it through a pull request. Claude Code can open the PR itself with a prompt like "create a pr for my changes", using gh pr create or glab mr create. It links the session to the PR, so claude --from-pr 1234 finds it later (common workflows). The same docs tell you to review Claude's generated PR before submitting and to ask it to highlight risks.

When the agent that wrote the code also writes the PR description, check the description as carefully as the code. Look for three things:

• It describes the diff, not the plan. If the plan said five things and the diff does four, the description should say four.
• It lists what wasn't done. Skipped tests, TODOs, and known gaps belong in the description, not in a later surprise.
• It says how it was verified. The command and the result, not "tested thoroughly".

Then review the diff itself, in the order from reviewing a coding agent's diff. The merge button stays with a human. Anthropic's auto-mode classifier blocks merging a PR no human has approved and approving Claude's own PR by default, which says something about where the vendor draws the line.

Parallel work with worktrees

Say you want one agent fixing a bug while another builds a feature. If both work in the same folder, they edit the same files and trip over each other.

A git worktree fixes that. It's a second copy of the same repository in its own folder, on its own branch, sharing one .git history. Each agent session gets its own worktree, so two can work at once without touching each other's files.

Sources: Claude Code worktrees and Codex worktrees, read September 26, 2026.

Three practical notes from those docs:

• Add .claude/worktrees/ to .gitignore, so worktree contents don't show up as untracked files in your main folder.
• Expect to install dependencies in each new worktree, because it starts as a fresh copy.
• Git lets a branch be checked out in only one place at a time. That's why Codex has its Handoff flow.

Worktrees stop two agents from editing the same file. They don't stop two agents from making changes that clash. One session can rename a function while the other adds a new call to the old name, and the merge breaks. Keep parallel tasks on separate parts of the codebase and merge them one at a time.

Clean up after yourself. Claude Code removes a clean worktree on exit for unnamed sessions and asks about one with changes. It doesn't clean up worktrees from non-interactive -p runs, so use git worktree remove for those, and git worktree list to see what's left.

What never to let an agent do

These stay with a human no matter the mode, the tool, or how well the last ten tasks went. Write them into the instruction file. Then back the most expensive ones with permission rules or hooks. The agent reads an instruction, but nothing forces it to follow one. A permission rule or hook actually blocks the action.

• Push to the main branch or force-push anywhere. Force push is on Claude Code's default block list for good reason. It rewrites shared history.
• Run destructive resets. git reset --hard, git clean -fd, git checkout -- . and git stash drop destroy uncommitted work, possibly yours.
• Rewrite published history. No amending or rebasing commits that are already pushed.
• Merge or approve its own pull request. Review is the point of the PR.
• Change git config or identity. A commit under the wrong author, or with signing turned off, is hard to undo once pushed.
• Commit secrets or generated artifacts. Check .env, keys, build output, and large binaries before any commit lands.
• Skip hooks. git commit --no-verify turns off the checks your team put there on purpose.
• Delete branches or worktrees it didn't create. They may hold someone's unpushed work.

Letting an agent do some of these on an isolated branch in a throwaway container is a different situation, covered in running coding agents headless and in CI. On your machine, in your repo, they stay yours.

A routine that holds up

Put together, a task looks like this:

1. Clean tree, new branch.
2. Plan if the diff won't fit in one sentence.
3. Agent implements one task and runs the check.
4. You review the diff: tests, deletions, dependencies, config, then the code.
5. Commit with a message that says why.
6. Repeat for the next task, then open a PR, review its description against the diff, and merge it yourself.

The routine costs a few extra commands per task. If you pay per token through the API, the attempts you throw away still cost money. The coding agent cost calculator shows what a month of that looks like next to a subscription.

For the instruction files that carry these rules across sessions, and how each tool loads them, see CLAUDE.md and AGENTS.md for coding agents.

Previous in the series: Reviewing a coding agent's diff. Next: Hooks for coding agents.