~/.traycer/worktrees folder, including ones whose Task was deleted.
For how worktrees affect agents and Git Diff, see Worktrees. The branch prefix for new worktrees is under Settings › General › Worktrees; see Branch Prefix.
To clean up worktrees for particular Tasks, open Sweep from the Task or History. The Sweep guide explains selection, shared worktrees, and stopping active work.
Controls
If the selected host is offline, worktrees can only be managed after that host is reachable again.
Worktree Rows
Worktrees are grouped by repository. Click a repository’s header to collapse or expand it; the number on the right counts its worktrees. Each row shows:- A status pill (see below). Hover it for the reason.
- Pull request chips, such as “#128 Merged”. Click one to open the PR. A submodule branch with commits that never landed shows a chip like “api · 2 unmerged commits”.
- The branch, or “detached HEAD”.
- A line of facts, such as uncommitted changes, and Last active time.
- The Tasks that use the worktree. Click a Task to open it. “Task Merged” or “Task Merged 1/2” shows how many of that Task’s branches have merged PRs. A worktree no Task uses reads “Not used by any Task”.
Each row’s ⋯ menu has:
Delete Worktrees
Delete one worktree from its ⋯ menu, or check several rows and click Delete N worktrees in the bar that appears (Clear empties the selection). Any row can be deleted once its status check has finished. The confirmation gets stronger when work could be lost:
Deleting runs the worktree’s teardown script, then removes the worktree. A single delete opens a progress dialog with Run teardown script and Remove worktree steps; Show output reveals the teardown output. Click Run in background to keep working while it runs; the row shows “Deleting…”. Several deletes run in the background, with progress above the list. Traycer runs up to two deletes at a time; the rest wait as Delete queued.
Deleting keeps the worktree’s branch. The exception is a submodule checked out on its own branch for that worktree: that branch is deleted with the worktree, along with any commits that exist only there.
Agent Worktrees
An agent can create worktrees itself, for example when it splits work across child agents that each need their own checkout. Agent worktrees in the worktree toolbar decides what happens when an agent running on the selected host asks for one:
With Ask first, an agent that another agent started, in a chat nobody has open, can’t reach you, so its request is refused and it reports back to the agent that started it. Open the agent’s chat before it asks if you want to approve worktrees for it, or ask the coordinating agent to create them.
The setting also covers
traycer worktree create when an agent runs it in its own shell. There it is refused under Never, and under Ask first too, because the command has no way to ask you. Running the command yourself is unaffected.
The setting covers the worktrees an agent asks Traycer for. It doesn’t change the coding agent itself: a worktree feature built into the agent’s own CLI (Claude Code’s worktree tool, for example) and git worktree add in the agent’s shell work as that CLI provides them. To turn those off, use the CLI’s own settings.
The setting applies from an agent’s next request, including agents already running: one that was started before you chose Ask first or Never is asked or refused the next time it tries. After you switch away from Never, an agent that started under it may not be offered worktrees again until it restarts.
The setting doesn’t affect worktrees you create yourself, or agents started on a worktree that already exists. An agent can still run git worktree add in a shell. Traycer tells agents when the setting is off or a request was refused, but it doesn’t block the command.
Automatic Cleanup
Automatic cleanup removes inactive, proven-safe Traycer-managed worktrees on the selected host without asking you to confirm each deletion. It is off by default, with a default inactivity threshold of 30 days. The setting applies across that host’s managed worktrees, not just the current Task. Configure each host separately. Cleanup runs on the host, so it does not require an open desktop window or Task.Enable, Adjust, Or Disable
- Open Settings › Worktrees and select the host you want to manage.
- Click Cleanup in the worktree toolbar, then turn on Automatic cleanup.
- Under Inactive for, choose 7, 14, 30, 60, or 90 days, or enter a whole number from 1 to 365. A custom value saves when you leave the field or press Enter.
- Check the toolbar label and the popover’s Last checked and next check times.
Which Worktrees Qualify?
Age alone never makes a worktree safe to delete. It must pass both the inactivity threshold and current safety checks.
Automatic cleanup leaves worktrees alone when they have uncommitted changes, unproven work, a detached HEAD, unreadable Git data, or orphaned metadata. It also skips worktrees with active agents, tasks, shells, terminals, or sessions holding them. It does not stop that activity to make a worktree eligible.
Missing activity information or an inconclusive required PR check also prevents deletion. A green status in the list is therefore not, by itself, a promise that automatic cleanup will remove the worktree.
Inactivity is measured from the most recent available creation time, Git reflog activity, and activity recorded by Traycer. Missing required activity records do not count as inactivity. A worktree can qualify while an idle Task still references it; the Task, conversations, and artifacts remain, but its saved worktree location becomes missing and must be replaced through the run-location picker.
When Cleanup Runs
While enabled and ready, the host normally checks every 24–26 hours. Enabling cleanup or changing its threshold schedules a check about 30 seconds later; the threshold measures existing inactivity, not time since you enabled the setting. Large inventories may take several passes, with history showing more to do next pass. If the host is stopped or asleep, cleanup resumes when it runs again. Cleanup pauses when host credentials need attention, the signed-in account does not match the account that authorized the setting, or startup and activity checks cannot establish that worktrees are unused. The popover explains the pause. The host resumes checks when the condition clears.What Gets Removed
Cleanup removes the eligible worktree directories. The removal operation does not delete local or remote branch refs or clear saved Task and agent bindings. Those bindings can point to a missing checkout afterward; choose an available run location before continuing work. Tasks, conversations, and artifacts remain available. A configured teardown script can perform additional actions, so check its contents when deciding what cleanup will remove. The host checks eligibility before running a configured teardown script and checks again afterward, before removal. If the worktree becomes active or unsafe, or the policy changes, it is skipped. A teardown error or timeout is recorded but does not itself guarantee that removal stops; deletion can still proceed if the safety checks pass.Cleanup History
While automatic cleanup is enabled, open Cleanup › History. Runs are listed newest first for the selected host, each with a summary such as “2 removed, 1 skipped, 0 failed” and the threshold it used. Expand a run to see its worktrees, paths, branches, status at selection, and outcome explanations. Automatic-cleanup notifications also link to the relevant run.
History records automatic runs only; manual deletion and Sweep do not appear here. Records stay on the host and are retained for up to 90 days, with a maximum of 200 runs. Turning cleanup off hides the History link but does not immediately erase those records.