Is a Worktree Temporary?

Yes, usually it is temporary.

In multi-task or multi-agent workflows, a worktree is best understood as a short-lived workspace that exists for the duration of a task.

The Hotel-Room Comparison Is Close Enough

A hotel room is a decent comparison:

Agent arrives      -> check in with git worktree add
Work is in progress -> edit code, stage changes, commit
Task is finished   -> check out with git worktree remove

The room disappears
The commits remain in Git history

A Typical Lifecycle

Most worktrees follow a short loop:

t0  A task arrives
t1  Create the worktree
t2  The agent works and commits inside it
t3  The main repo merges the branch
t4  Remove the worktree and delete the temporary branch

For example:

git worktree add /tmp/task-001 -b refactor-user
git worktree add /tmp/task-002 -b fix-payment

After the work is done:
git merge refactor-user
git merge fix-payment
git worktree remove /tmp/task-001
git worktree remove /tmp/task-002
git branch -d refactor-user
git branch -d fix-payment

What gets deleted is the working directory, not the commits that were recorded in Git.

Why Not Keep Worktrees Around Permanently?

Three reasons come up again and again:

1. wasted resources
2. branch lock-in
3. stale state

1. Wasted Resources

Each worktree contains a full working file tree. If the task is finished, keeping that directory around usually provides no value.

2. Branch Lock-In

Git does not allow the same branch to be checked out in multiple worktrees at once.

So a forgotten long-lived worktree can block other workflows from using that branch.

fatal: 'refactor-user' is already checked out at '/tmp/task-001'

3. Stale State

The longer a worktree sits around, the further it tends to drift from the main branch. That raises merge cost and makes the environment harder to trust.

For that reason, long-lived worktrees are usually a smell. The directory is temporary. The Git history is the part that lasts.