[Bug]: MacOs T3 fills up disk #10953

Activity

1. robert2411

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 9, 2026
2. juliusmarminge commented on Sep 9, 2026

   

   juliusmarminge

   on Sep 9, 2026

   Member

   More actions

   Triage

   This matches current shipped behavior, not a regression and not a wash of #9085.

   New worktree (defaultThreadEnvMode = "worktree") creates a full git checkout under the environment’s worktrees/ directory for each chat ({T3 home}/worktrees/<repo>/<branch>). A project setup script can also run there, so each thread can carry its own node_modules / build artifacts. macOS is incidental — the same lifecycle exists on every platform.

   On main those directories are not reaped by settle, archive, inactivity, or PR merge. The only removal path is the desktop “Delete the worktree too?” prompt after thread delete (useThreadActions + worktreeCleanup). That prompt is gated on localApi, so web and mobile never clean up. Server thread.delete does not touch disk. git worktree prune only drops stale Git admin entries after a directory is already gone.

   Why this is not #9085

   #9085 / PR #9116 are a delete-path bug: deleting an archived thread skips that prompt and orphans the worktree. Landing #9116 still leaves this report open — creating many New-worktree chats without deleting them (or settling/archiving them) will keep filling the disk. The autoclean comment on #9085 is the same product ask as this issue.

   Related work (already accepted, not shipped)

   • [Feature]: Clean up worktrees for settled threads without deleting history #5208 / [Feature]: Automatically clean up old and inactive Git worktrees #5269 / [Feature]: Add per-project retention limits for settled worktrees #6659 asked for manual remove-without-deleting-history, TTL/inactive cleanup, and retention limits. They were converted to Discussions (2026-08-15), not implemented.
   • PR Add safe worktree inventory, pruning, and revival #4742 implemented inventory + reaper + settings and was closed unmerged.
   • PR feat(worktrees): manage lifecycle on orchestrator v2 #5589 is the successor on orchestrator v2 (stacked on still-open feat(orchestrator): introduce new orchestrator #2829): server-owned inventory, safe prune, configurable autoPruneAfterDays (default 14), optional immediate orphan cleanup, and revival. That is the intended fix for this report.
   • [Bug]: Background git fetch fills up entire disk when fetch exceeds the 5s timeout (regression of #1965) #3525 is a different disk-fill (tmp_pack_* from timed-out git fetch).

   Workaround

   Delete the thread on desktop and confirm worktree removal, or remove the trees yourself (git worktree remove / delete under ~/.t3/worktrees). To avoid growth, use Current checkout or New thread in this worktree instead of New worktree per chat.

   Keeping this open as the live disk-growth report for the missing worktree lifecycle. No new product call — #5589 is the plan.
3. juliusmarminge

   added

   enhancementRequested improvement or new capability.Requested improvement or new capability.

   acceptedfeature request acceptedfeature request accepted

   planned

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 9, 2026
4. wouteth commented on Sep 11, 2026

   

   wouteth

   on Sep 11, 2026

   Last edited by wouteth

   More actions

   Correction to my previous cross-reference:

   The earlier 997 ms t3code-3c0f8faf failure was not a valid clean reproduction. Our external janitor had already moved and deregistered that worktree about 2 hours 39 minutes earlier, so T3 was acting on stale thread/worktree state.

   A subsequent untouched T3 Code 0.0.40 removal of t3code-f1f40334 did fail independently: Git exited 255 after 11.13 seconds, the .git pointer and Git registration were removed, but most of the checkout remained on disk, including 2,793 pnpm package directories. That is a genuine partially removed orphan and was not caused by the five-minute timeout.

   The trace records only stderr length 96, so the initiating filesystem/Git cause remains unknown. The supported conclusion is that non-timeout partial removals can still strand directories and need retry/reconciliation. I posted the complete corrected evidence on #5614.