Cleanup is part of the run, not an afterthought
An AI coding agent branch is not finished when the diff looks good. It is finished when the work has a clear Git ending: merge, delete, keep for review, or archive for evidence.
That matters because Claude Code and Codex often create branches faster than humans clean them up. If you do not define a cleanup rule, the repository slowly fills with branches that nobody can explain.
Junction helps by keeping the run, the diff, and the branch state visible together. The cleanup decision still belongs to you.
Use four cleanup outcomes
Every agent branch should land in one of four outcomes:
| Outcome | When to use it |
|---|---|
| Merge | The branch is reviewed, tested, and ready to land. |
| Delete | The branch is merged and no longer needed. |
| Keep | The branch still needs review, testing, or follow-up. |
| Prune | The worktree or local metadata is stale and should be removed. |
This is simpler than trying to invent a special case every time.
Merge only when the story is coherent
Merge is the right outcome when the branch tells one clean story:
- the task matches the branch name,
- the diff stays in scope,
- the verification steps make sense,
- and the reviewer can understand what changed.
If the branch contains unrelated cleanup, stale experiments, or a surprise file change, it is not ready to merge yet. Cleanups that are obvious to the agent are not always obvious to the reviewer.
Delete the branch after the merge
Once a branch is merged, keeping it around usually adds more noise than value.
Deletion is especially helpful when:
- the PR is closed,
- the worktree is no longer needed,
- and the same branch name would be confusing if it reappeared later.
That does not mean the evidence disappears. The transcript, PR, and diff history still exist. The branch just stops competing for attention.
Keep branches that still explain something
Not every branch should be deleted immediately.
Keep a branch when:
- the review is incomplete,
- the change is blocked on another decision,
- the branch contains useful evidence,
- or the work will continue in the same line soon.
That is especially true for a branch that serves as a reference point during debugging. If you do not yet understand why it exists, do not rush to destroy it.
Prune stale worktrees and metadata
Cleanup is not only about branch refs. Worktrees and local metadata can go stale too.
Common cleanup commands look like this:
git worktree list
git worktree remove ../some-worktree
git worktree prune
git branch -d fix/pricing-empty-stateThe important part is not the command itself. It is the order:
- Confirm the worktree is no longer needed.
- Confirm the branch has a safe ending.
- Remove stale local state.
If the worktree still contains useful changes, clean the branch story first.
A cleanup checklist
Before you delete or prune, ask:
- Has the change been merged or intentionally abandoned?
- Is there an open PR still using this branch?
- Does the transcript explain why the branch exists?
- Is the worktree clean?
- Will the cleanup destroy useful evidence?
If the answer is unclear, keep the branch for now.
That checklist is especially useful when you are managing several runs at once. A cleanup pass should reduce confusion, not create it.
A concrete example
Suppose an agent used a dedicated worktree for a pricing copy change.
The correct ending might be:
- Review the diff.
- Merge the pull request.
- Delete the branch.
- Remove the worktree.
- Prune stale metadata.
If the same branch also contained a failed experiment, you might keep the transcript but still remove the worktree once the useful part is done.
The key is separating the evidence from the temporary workspace.
Watch for cleanup traps
Cleanup gets messy when the branch story and the local state diverge.
Watch for:
- branches with uncommitted work,
- worktrees that still have manual edits,
- PRs that were never reviewed,
- or branches whose names no longer match the diff.
Those are signs that the cleanup pass needs a human review before any destructive action.
How this relates to recovery
Cleanup and recovery are related but not identical.
Recovery asks: "Can we salvage useful work from this run?" Cleanup asks: "What is the right final state after the work is known?"
If the branch is broken, read How to Recover from a Bad Branch or Workspace Drift before you delete anything. If the branch was clean from the start, branch suggestions and worktree isolation make cleanup much easier; see Use Branch Suggestions to Keep Agent Runs Reviewable and Git Worktree Isolation for AI Coding Agents.
Tradeoffs
The main tradeoff is time. Cleanup adds one more pass after the work is done.
The return is a repo that still makes sense a week later. That is worth more than a directory full of half-merged branches that only the original author can decode.
The other tradeoff is evidence retention. Be careful not to delete the only clue that explains a failed or abandoned run. When in doubt, keep the transcript and remove the workspace later.
Where Junction fits
Junction makes the cleanup decision easier because you can see the run state, the diff, and the Git story in one place before you act. That is a better place to make a delete-or-keep call than a terminal prompt with no context.
If you want the workflow to stay local and reviewable, start with the setup guide and compare pricing once you know how many daemons and open chats your cleanup habits need to support.