You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Storage cleanup never removes worktrees in ~/.t3/worktrees that no thread owns, so agent-created worktrees pile up #25843
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
Turn storage cleanup on (worktreeAfterDays: 7, worktreeSettledAfterDays: 2, worktreeOnMerge, worktreeOnDelete and worktreeUnchanged all on).
In a thread, let the agent create its own worktree inside T3's worktrees folder, for example git -C <project> worktree add ~/.t3/worktrees/<project>/review-123 -b review-123. Agents do this often when they want a second checkout for a review or a PR push.
Finish the work, push the branch, and leave the worktree clean.
Wait more than 7 days, or run storage cleanup by hand.
Expected behavior
A clean worktree under ~/.t3/worktrees/ whose commits are on a remote, and which no thread uses, is removed by cleanup with the same safety checks as thread worktrees. At minimum, the storage panel offers a way to remove it.
Actual behavior
The storage report lists it as "No thread uses this worktree", but cleanup never removes it. In the trace, StorageCleanup.sweep → cleanWorktrees → reportOrphanWorktrees succeeds on every run. The only "storage cleanup removed worktree" events are for worktrees with a threadId.
On one machine this left 81 orphaned worktrees in the report, from 0 to 14 days old (24 of them older than the 7-day setting). None used T3's t3-<id> naming, so all were created by agents. Across the whole folder there were about 194 registered worktrees, about 150 of them agent-named, and the disk reached 97% full.
Impact
Major degradation or frequent failure
Version or commit
0.1.3-nightly.20261027.3754
Environment
Ubuntu, Linux 7.0, desktop app. Claude and Codex providers, many delegated tasks.
Workaround
Remove them by hand: for each worktree with an empty git status --porcelain whose HEAD shows up in git branch -r --contains, run git worktree remove.
Reacted by Victor Lapa, Christian Rank and Florent Klein
Confirmed by source inspection of current main at 0f4a130. reportOrphanWorktrees still only records these paths as kept; it does not call the removal path (source). The existing test “reports a linked orphan's size without removing its files” explicitly preserves them (test).
This matches a report from macOS 27 on desktop nightly 0.1.8-nightly.20261104.4165. The installed app was not modified and cleanup was not run during this investigation. No new duplicate issue or removal PR: automatically deleting previously unmanaged worktrees needs an agreed ownership, age and safety policy first.
Investigated with GPT-6.1 Sol via Codex in T3 Code.
Activity
rieckt commentedon Nov 7, 2026
Confirmed by source inspection of current main at 0f4a130.
reportOrphanWorktreesstill only records these paths as kept; it does not call the removal path (source). The existing test “reports a linked orphan's size without removing its files” explicitly preserves them (test).This matches a report from macOS 27 on desktop nightly 0.1.8-nightly.20261104.4165. The installed app was not modified and cleanup was not run during this investigation. No new duplicate issue or removal PR: automatically deleting previously unmanaged worktrees needs an agreed ownership, age and safety policy first.
Investigated with GPT-6.1 Sol via Codex in T3 Code.