Before submitting
Area
apps/desktop
Problem or use case
I currently maintain 22 projects with T3 Code and regularly run into storage constraints because Git worktrees accumulate over time.
Many of these worktrees belong to completed or abandoned tasks and are no longer needed, but identifying and removing them manually is time-consuming. Each worktree may also contain its own dependencies, build artifacts, and caches, so the total storage usage can become significant.
I would like a safe, rule-based way to identify and remove old, inactive worktrees without risking the loss of uncommitted, unpushed, or otherwise important work.
Proposed solution
Add an opt-in worktree cleanup feature with configurable safety rules.
For example, users could choose to mark a worktree as eligible for cleanup when all of the following are true:
- It has not been used for a configurable number of days.
- The working tree is clean.
- All commits are available on a configured remote.
- The associated task or conversation is no longer active.
- The worktree is not pinned or explicitly excluded.
The UI should show the worktrees that match the rules, their age, project, branch, storage usage, and the reason each one is considered safe to remove.
A preview and confirmation step should be shown before deletion. Automatic cleanup could be offered as a separate, optional setting after the manual review flow is established.
Why this matters
Users who work across many projects or create frequent task-specific worktrees can accumulate tens if not hundreds of gigabytes of unused data.
A safe cleanup workflow would reduce storage usage, avoid repeated manual maintenance, and make long-term use of the app more sustainable without putting active or unpublished work at risk.
Smallest useful scope
The smallest useful version would be a manual cleanup screen that lists inactive worktrees older than a configurable age.
It should only include worktrees that have a clean working tree and whose commits are already available on a remote. The user can then review and explicitly select which worktrees to delete.
Automatic scheduled deletion is not required for the first version.
Alternatives considered
I currently inspect and remove worktrees manually using Git commands and the filesystem.
I have also deleted dependency folders and caches separately, but this requires checking many project directories and does not remove worktrees that are no longer needed.
External disk-cleanup tools can identify large folders, but they do not understand whether a worktree is active, clean, pushed, or associated with an ongoing task.
Risks or tradeoffs
The main risk is deleting work that has not been preserved elsewhere.
The cleanup logic must distinguish between committed, pushed, and merged changes. A committed worktree is not necessarily safe to delete if its commits have not been pushed to a remote.
Other edge cases include:
- Detached HEAD worktrees
- Deleted or unavailable remotes
- Commits that were pushed but not merged
- Submodules or nested repositories
- Worktrees used by active tasks
- Untracked or ignored files containing important data
- Large dependency or cache directories that can be regenerated
- Worktrees stored outside the default project directory
The feature should be opt-in, conservative by default, and provide a clear preview before deleting anything. Supporting exclusions or pinned worktrees would further reduce risk.
Examples or references
A possible cleanup screen could show:
Project: JSON
Branch: feature/acme-json
Last used: 34 days ago
Working tree: Clean
Remote status: Fully pushed
Task status: Settled
Storage usage: 4.8 GB
Cleanup eligibility: Safe to review
Actions:
- Open worktree
- Pin
- Delete
- Exclude from cleanup
A summary could also show the total recoverable storage before confirmation.
Contribution
Before submitting
Area
apps/desktop
Problem or use case
I currently maintain 22 projects with T3 Code and regularly run into storage constraints because Git worktrees accumulate over time.
Many of these worktrees belong to completed or abandoned tasks and are no longer needed, but identifying and removing them manually is time-consuming. Each worktree may also contain its own dependencies, build artifacts, and caches, so the total storage usage can become significant.
I would like a safe, rule-based way to identify and remove old, inactive worktrees without risking the loss of uncommitted, unpushed, or otherwise important work.
Proposed solution
Add an opt-in worktree cleanup feature with configurable safety rules.
For example, users could choose to mark a worktree as eligible for cleanup when all of the following are true:
The UI should show the worktrees that match the rules, their age, project, branch, storage usage, and the reason each one is considered safe to remove.
A preview and confirmation step should be shown before deletion. Automatic cleanup could be offered as a separate, optional setting after the manual review flow is established.
Why this matters
Users who work across many projects or create frequent task-specific worktrees can accumulate tens if not hundreds of gigabytes of unused data.
A safe cleanup workflow would reduce storage usage, avoid repeated manual maintenance, and make long-term use of the app more sustainable without putting active or unpublished work at risk.
Smallest useful scope
The smallest useful version would be a manual cleanup screen that lists inactive worktrees older than a configurable age.
It should only include worktrees that have a clean working tree and whose commits are already available on a remote. The user can then review and explicitly select which worktrees to delete.
Automatic scheduled deletion is not required for the first version.
Alternatives considered
I currently inspect and remove worktrees manually using Git commands and the filesystem.
I have also deleted dependency folders and caches separately, but this requires checking many project directories and does not remove worktrees that are no longer needed.
External disk-cleanup tools can identify large folders, but they do not understand whether a worktree is active, clean, pushed, or associated with an ongoing task.
Risks or tradeoffs
The main risk is deleting work that has not been preserved elsewhere.
The cleanup logic must distinguish between committed, pushed, and merged changes. A committed worktree is not necessarily safe to delete if its commits have not been pushed to a remote.
Other edge cases include:
The feature should be opt-in, conservative by default, and provide a clear preview before deleting anything. Supporting exclusions or pinned worktrees would further reduce risk.
Examples or references
A possible cleanup screen could show:
Project: JSON
Branch: feature/acme-json
Last used: 34 days ago
Working tree: Clean
Remote status: Fully pushed
Task status: Settled
Storage usage: 4.8 GB
Cleanup eligibility: Safe to review
Actions:
A summary could also show the total recoverable storage before confirmation.
Contribution