[Feature Request] Configurable automatic cleanup of worktrees

[alcibiadesc]

USER STORY

AS a Vibe Kanban user
I WANT to configure in Settings the automatic cleanup of worktrees in Done or Cancel state after a defined retention period
SO THAT legacy worktrees are eliminated and system storage is optimized

FUNCTIONAL ASPECTS

• Add a toggle in Settings to enable/disable automatic cleanup.
• Allow configuration of retention period in hours (e.g., 1h, 24h, 72h).
• The system should automatically delete worktrees that meet the criteria.
• Log cleanup actions for traceability.

ACCEPTANCE CRITERIA

GIVEN a user has a worktree in Done state
WHEN the configured retention period has passed
THEN the system should automatically remove that Git worktree, detach it from the repository, and log the action

GIVEN a user has disabled the option in Settings
WHEN the retention period has passed
THEN the system should not delete or detach any Git worktree

[stunningpixels]

Thanks, I'm keen to understand the motivation here - are worktrees taking up too much space?

[alcibiadesc]

@stunningpixels In my case, with an average of two days of use, developing an end-to-end project (frontend, backend, and database), and also heavily using the start Dev Server Script—which is fantastic in how well it’s integrated—it’s around 26 GB

[stunningpixels]

Thanks, we have done a few rounds of trying to optimise this but it sounds like another is due. The issue with adding a setting is that 99% of users won't find it, so if we can do this smarter than just "set timer for all tasks" that's preferable

[alcibiadesc]

@stunningpixels I agree with your point, maybe it could even be the default behavior for canceled tasks.

If it’s hidden only in Settings, power users would probably look there, but another option could be: when a task is moved to Done or Canceled, show a “Remove worktree” action inline. If executed, it removes it immediately, and just below that we could include a small hyperlink to the Settings page for configuring periodic cleanup.

This way, casual users get the visible option, while advanced users can set it up once and forget about it.

[norton120]

I think I made a rational assumption that VK garbage collected worktrees once a task is moved to Done or Cancelled, and I was surprised to learn that isn't the case. I feel like "leaves garbage files piling up in tmp dirs" would usually be considered a bug, or at the very least a pretty critical feature.

I guess a user could possibly move work backwards from Done or Cancelled into In Progress and might expect the previous state to persist, but that feels like an antipattern (at least the way I have been using VK). Maybe ➕ then to @alcibiadesc 's suggestion to this being a setting like "delete worktrees upon completion." I don't know that I'd expect a retention period as a user, just a checkbox to either delete the worktree (or not) when a card is moved all the way to the right would be great.

[adamtaylor13]

I was surprised when I went to manually remove a worktree + branch—VK recreated it automatically. I didn't like that.

Part of my issue is that I do still open my IDE/manually look at my code enough that I want to treat worktrees like the first-class citizens they are. When I close a ticket, I still have worktrees lying about, which makes it harder as my list of completed tasks grows.

[stunningpixels]

Hey @adamtaylor13 worktrees should only get recreated if you open the task attempt, otherwise they will remain deleted.

Worktrees are automatically deleted after 72h of inactivity.

[adamtaylor13]

This is good to know. Curious: Why 72h of inactivity? Why not just delete them as soon as the task moves to "Done" and/or the PR is merged? You'd likely want to branch back off the primary branch at that point anyway.

[stunningpixels]

We could delete right after, but people do sometimes click on the task attempt again right after to create a subtask or just view the changes - so it'd get re-created right after.

Fixed time like 72h isn't ideal, but it's longer than a weekend but after tweaking higher and lower seems like the most balanced.

[adamtaylor13]

That makes sense. Well no worries, I've just written some custom bash helpers to help me with my particular workflows. Thanks for clarifying the expected behavior. I didn't know that about clicking on the closed task!