Skip to content

[Bug]: Storage cleanup never removes worktrees in ~/.t3/worktrees that no thread owns, so agent-created worktrees pile up #25843

Open

Description

@joneriktalvio

Before submitting

  • 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

  1. Turn storage cleanup on (worktreeAfterDays: 7, worktreeSettledAfterDays: 2, worktreeOnMerge, worktreeOnDelete and worktreeUnchanged all on).
  2. 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.
  3. Finish the work, push the branch, and leave the worktree clean.
  4. 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.

Activity

  1. rieckt commented on Nov 7, 2026

    @rieckt

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions