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 are built around a Git repository. Codex even decides its default permissions based on whether the folder is version-controlled. The docs cover the mechanics. This page puts them into a routine and adds the parts the docs leave to you.

Checkpoint before every task

Start each task from a clean working tree. 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 code, conversation, or both. The docs are explicit about the limit: checkpoints track only 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 agent-sized tasks, as in the plan mode guide, commit after each one passes its check. You get a clean diff for the next task and a named point to reset 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, because a rule you type once per session is a rule you'll forget to type.

Commit message discipline

Left without rules, a commit message can end up as a list of the files touched, which git show --stat already gives you. A useful message says what changed and why, in a form someone can search for a year from now. Rules 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 adds attribution by default: a Co-Authored-By trailer on commits and a line in pull request descriptions. You can change or remove both with the attribution setting. The deprecated includeCoAuthoredBy still works but new configurations should use attribution (settings reference). The docs also note that your own attribution instructions in CLAUDE.md take precedence over those default lines, unless they're set in managed settings. Whatever you pick, pick it deliberately, because a commit trailer is a permanent record of who wrote the code.

How each tool handles commits

The two tools put the permission boundary in different places:

• Codex. In the default workspace-write sandbox, the .git directory is protected as 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, needs to leave 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 classifier reviews each action, 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, or in Claude Code add a permission rule, which blocks 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.

A PR description written by the agent that wrote the code needs the same scrutiny as the code. Check 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

A git worktree is a second checkout of the same repository, with its own files and branch, sharing one .git history. It lets two agent sessions work at once without editing the same 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 checkout. Expect to install dependencies in each new worktree, because it's a fresh checkout. And remember that git allows a branch to be checked out in only one place at a time, which is why Codex's Handoff flow exists.

Worktrees solve file collisions, not logical ones. Two sessions editing different files can still make changes that conflict when merged. 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 regardless of mode, tool, or how well the last ten tasks went. Write them into the instruction file and back the most expensive ones with permission rules or hooks, because an instruction is context, not enforcement.

• 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 these on an isolated branch in a throwaway container is a different situation, which the headless and CI page later in this series covers. 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 cost of this routine is a few extra commands per task. On API billing, the throwaway attempts it makes safe still cost tokens, and the coding agent cost calculator shows what a month of that looks like next to a subscription.

For the context features that carry these rules across sessions, see Claude Code features that matter after the first demo. For how instruction files load in each tool, see CLAUDE.md and AGENTS.md for coding agents.

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