Repository navigation
[Bug]: Settling a thread leaves its child threads open, so their worktrees are never cleaned up #29999
Description
Area
Threads: settle, subagents and delegated tasks, storage cleanup (worktrees)
Steps to reproduce
- Settings → Storage → Cleanup: turn on Delete settled worktrees (
storageCleanup.worktreeSettledAfterDays: 0). - In a worktree thread, have the agent start child threads that get their own worktree (
delegate_taskwithisolation: "worktree", or a reviewer delegate). - Let the children finish, merge the work, then settle the parent thread.
Expected behavior
Settling a thread settles its finished child threads too (subagents and delegated tasks it started), so storage cleanup removes the children's worktrees along with the parent's. The user cannot see most child threads in the sidebar and has no practical way to settle them one by one.
Actual behavior
thread.settle updates only the thread it targets (Orchestrator.ts, case "thread.settle"). Children keep settledAt: null. storageCleanup.ts evaluates a child that has its own worktree on the child's own settledAt, so with only settled-age cleanup turned on those worktrees are never removed. Delete merged worktrees often does not catch them either, because a child's branch is usually merged into the parent's branch, not the default branch.
Impact
On two machines in daily use, from orchestration_v2_projection_threads (lineage.parentThreadId, settledAt, worktreePath):
| child threads | machine A | machine B |
|---|---|---|
| parent settled, child open, child has its own worktree | 192 | 89 |
| parent settled, child open, no own worktree | 516 | 100 |
| parent settled, child settled | 0 | 51 |
Machine B held 176 worktrees for one repository (160 GB), and machine A's disk reached 81%. We removed 183 worktrees by hand. Each one was held only by finished child or settled threads, had been idle for 24 h, had no uncommitted changes, and had all its commits on a remote.
Possible fixes:
- Settling a thread also settles its idle descendants (subagent and delegated-task lineage), or
- storage cleanup treats a child as settled once its root thread is settled and the child is idle.
Related: #19657 (hidden subagent threads as auto-settle candidates), #17548 (settling a delegated subagent runs the settle hook in the parent's worktree).
Version or commit
0.1.6-nightly.20261031.3977 (installed); the same code is in main at e1e520c (3 Nov).
Environment
Linux (Ubuntu), T3 Code background service. Two linked environments, Claude and Codex providers, heavy delegate_task use.
Activity
ilyesm commentedon Nov 3, 2026
Additional evidence from a Mac Studio running the T3 desktop app, version
0.1.7-nightly.20261102.4080. The user reports that Settings → Storage cleanup leaves substantial disk usage behind.Read-only inspection found:
These observations match the relationship described in this issue. We have not reproduced the cleanup action or collected its kept/failed reasons, so we cannot yet confirm which directories are blocked specifically by settlement inheritance or are otherwise eligible for removal.
The data volume had 6.1 GiB available and was 99% full during inspection. Separately, the history database occupied 30.7 GiB; this build’s storage cleanup does not prune it. That usage should not be attributed to this child-worktree bug.
No database writes or worktree deletions were performed during triage. PR #30026 has not been tested on this Mac.
Prepared by Codex (GPT-6).