[Bug]: Automatic worktree cleanup never removes worktrees set up by t3.json's Setup Worktree action

[leomontigatti]

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. In pingdotgg/t3code, import the t3.json "Setup Worktree" action and start a thread in a new worktree. scripts/setup-worktree.ts symlinks $T3CODE_PROJECT_ROOT/.env into the worktree.
2. Settle or delete the thread, leaving the worktree clean (no working-tree changes).
3. Enable Settings → Storage → automatic worktree cleanup (for example "Delete worktrees with deleted threads", or an inactivity rule).
4. Wait for the next cleanup pass.

Expected behavior

The worktree is removed: it has no local changes, and everything in it can be recreated by running the setup action again.

Actual behavior

The worktree is kept. Before removing a worktree, storageCleanup.ts lists its gitignored files, and any entry other than node_modules/ blocks removal (L226–L239, repeated at L331–L342):

git ls-files --others --ignored --exclude-standard --directory

The .env symlink created by the setup action is gitignored, so it always appears in that list. In practice, every worktree the recommended setup action has run in is ineligible. Other repos hit the same thing with ordinary generated output; in ours, setup also leaves .husky/_/ (written by husky's prepare script during install) and .react-router/ (route type generation).

The guard exists for a good reason, since ignored files can hold secrets or local data. But its only exception is a hardcoded, Node-specific node_modules/. Two changes that could each land independently:

1. Treat symlinks pointing outside the worktree as safe to remove. Removing the worktree deletes the link, not its target. This is small and fixes this repo's own .env and infra/relay/.env links.
2. Replace the node_modules/ special case with a general rule for reproducible paths, so it works for any language (.venv/, target/, __pycache__/, .next/, vendor/, generated types, git hook shims). Two possible shapes:
   • Baseline after setup (preferred). T3 already runs runOnWorktreeCreate, so it can record the ignored-path listing right after setup succeeds. Anything in that baseline can be recreated by running setup again and shouldn't block removal. It needs no configuration, and paths created later still block: .t3/ dev userdata only appears once a dev server runs, so it stays protected. Worktrees created before this change have no baseline and keep today's behavior.
   • Declared in t3.json. For example cleanup.reproduciblePaths: ["node_modules/", ...], defaulting to today's ["node_modules/"]. More explicit and reviewable, but each repo has to maintain the list. This follows feat(settings): resolve t3.json inside the project settings resolver #12954's pattern of letting t3.json provide settings.

Impact

Minor bug or occasional failure

Version or commit

Read from source at 6530de0339d2 (v0.0.43-nightly.20260926.2282), not yet run on a nightly. The ignored-files listing was checked locally: a symlinked .env appears in it.

Environment

Linux, T3 Code desktop 0.0.42 (AppImage).

Workaround

Delete threads by hand and confirm "Delete the worktree too?", or run git worktree remove yourself.

[RustedAperture]

I was just looking for this, my settled was getting up in the hundred and couldn't figure out why. turns out git ignored files block the cleanup. looking forward to #12604 being merged

[RSpencerFink]

+1 to this

[glarivie]

Same behaviour here with the inactivity rule set to 5 days. A cleanup pass ran and removed nothing. Replaying the conditions of cleanWorktrees by hand on 119 worktrees with an inactive thread: 85 were blocked only by the ignored-files guard, 33 by local changes, 1 was eligible. The refusal is logged at debug level, so nothing in the default logs explains why a worktree is kept. An info-level line with the blocking reason, or a count of blocked worktrees in the storage settings, would make this diagnosable.

[saibotma]

Another data point, from a polyglot monorepo (Flutter, Kotlin/Gradle, Next.js). Our runOnWorktreeCreate script runs pub get, npm ci, and Gradle setup, and writes a per-worktree api/.env.local that points at that worktree's own local database. Right after setup, a worktree has 36 ignored entries outside node_modules/, for example app/.dart_tool/, .gradle/, .fvm/, api/.env.local, and generated platform files like app/ios/Flutter/Generated.xcconfig. So today no cleanup rule can remove any of our worktrees.

On the proposed fixes, we'd prefer the approach from #12604: let .gitignore decide. Ignored files would no longer block removal; only tracked changes and non-ignored untracked files would. A baseline after setup would only partly help us, because normal work keeps adding ignored output after setup, for example Gradle build/ directories of modules that setup didn't build, and test and coverage reports. A path list in t3.json would work, but it would duplicate what .gitignore already says.

[BenWortley]

Note

Written by Claude Opus 5.5 on behalf of @BenWortley.

A data point from Laravel. On 0.0.46-nightly.20261005.2667 (Linux), I ran the guard's git ls-files --others --ignored --exclude-standard --directory in every T3 worktree of three Laravel apps. 199 of 200 have an ignored entry other than node_modules/, so no cleanup rule can remove them.

The entries are what any Laravel checkout has after composer install and a test run: vendor/, .env, bootstrap/cache/*.php, public/build/, storage/framework/views/, plus generated route helpers (resources/js/wayfinder/) and .husky/_/. Each worktree is about 1.2 GB. The VM's disk filled up today with 220 of them.

The setup-baseline idea in the report would cover all of these, because our runOnWorktreeCreate action creates them.

[ImNallen]

Note

Written by Claude Opus 5.5 on behalf of @ImNallen.

Two things not covered above, from T3 Code 0.0.45 on macOS:

1. With "Delete worktrees with deleted threads" on, the workaround in this report is unavailable. useThreadActions.ts only shows the "Delete the worktree too?" dialog when that rule is off (canDeleteWorktree && localApi && !automaticWorktreeCleanup, L471). With the rule on, shouldDeleteWorktree stays false and removal is left to the sweep, which this guard blocks. So turning the rule on makes a deleted thread's worktree less likely to be removed than leaving it off, where confirming the dialog force-removes it. Nothing in the UI says the worktree was kept.

2. .DS_Store alone blocks removal. Finder writes it into any folder you open, and most macOS repos ignore it. In one of my repos it is the only ignored entry outside node_modules/, so opening a worktree in Finder once makes it permanent. A setup baseline wouldn't catch it, because Finder writes it later. With #15434 every macOS user would have to add it to the disposable list by hand. It could be a default, along with Thumbs.db and desktop.ini.

Other data from my repos, using the guard's listing:

Stack	Ignored entries outside node_modules/
Rust + Tauri	target/, src-tauri/gen/, .DS_Store
.NET	bin/, obj/ per project
Tauri app	src-tauri/gen/, .DS_Store
Vite app	.DS_Store

Over 52 StorageCleanup.cleanWorktrees runs in my server trace files, cleanup removed one worktree. I then removed 43 T3 worktrees by hand. Every one of their branches had already landed on main, and the Rust project's worktrees alone took 61 GB. At the time, I had worktreeOnDelete, worktreeOnMerge, worktreeUnchanged and an 8-day age rule all enabled.