Repository navigation
[Bug]: Worktree not removed after its PR merged, with worktree cleanup enabled and no explanation shown #24188
Description
Before submitting
- I searched existing issues and did not find a duplicate. Related but different: [Bug]: Deleting a thread leaves its subagent threads behind, so "Delete worktrees with deleted threads" never removes the worktree #17812, [Bug]: Merged-worktree cleanup retains worktrees after squash merges #14742, Storage cleanup never removes a worktree that a subagent thread used #19144, [Bug]: Storage cleanup never sees archived threads, so their worktrees are never removed and do not count as sharers #17811.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Enable automatic worktree cleanup in Settings → Storage.
- Start a worktree thread, have the agent commit, push and open a PR from the worktree branch.
- Merge the PR. The thread stays open and the agent session keeps running in the worktree.
- Wait for the hourly cleanup sweep.
Expected behavior
The worktree is removed once the PR is merged, or the UI clearly says why it was kept.
Actual behavior
The worktree is still on disk after the PR merged and after several hours. Nothing in the UI I looked at explained why.
What I verified locally:
git statusin the worktree is clean (no uncommitted changes).- Worktree
HEADequals the merged PR's head commit (9c6348b…). - PR state is
MERGED; head branch and base (main) match whatstorageCleanupPullRequestMergedrequires. git worktree liststill lists it.
Reading apps/server/src/storageCleanup.ts, my best guess is that the thread is still active (agent session running with its cwd inside the worktree), which maps to the "thread is running or has pending work" or "provider session is still open" keep reasons. I have not confirmed this from the cleanup report.
Impact
Minor bug or occasional failure
Version or commit
Unknown
Environment
macOS (Darwin 27.0.0), T3 Code with the Claude Code harness, model Claude Sonnet 5.5. Date: 2026-10-23.
Logs or stack traces
N/A
Workaround
Settle or delete the thread so the session closes, then run cleanup now, or run git worktree remove manually.
Suggestions
- If a merged-PR worktree is kept only because its thread or session is still active, say so in the Storage cleanup report and in the thread UI.
- Consider whether a merged PR should count as enough to settle the thread, so cleanup is not blocked by an idle-but-open session.
Activity
juliusmarminge commentedon Oct 24, 2026
On current main (d53873b6a4), I ran the web app and server on Linux with a clean worktree and a real Claude Sonnet 5.5 turn. With Delete merged worktrees enabled, Delete now kept the running worktree and Settings → Storage → Cleanup → Last run displayed “Thread is running or has pending work.” I could not reproduce the missing explanation.
The historical merged-PR head used for this attempt was not an ancestor of current main; after the turn finished, its report said “Not merged,” so this does not establish the idle-session behavior for your integrated branch.
Please provide your T3 version, the merged PR URL, and the entry for this worktree under Storage → Cleanup → Last run after Delete now. That will distinguish an active-session guard from an integration check or a missing report entry.