Repository navigation
Feature request: Built-in git worktree lifecycle management #1613
Description
Activity
In addition to native worktree lifecycle management, I'd like to request feature parity with Claude Code's
WorktreeCreateandWorktreeRemovehook events (Claude Code hooks reference).Claude Code fires these hooks at the worktree level — separate from sessionStart — specifically when a worktree is created or removed. Common use cases include running
git lfs pullandnpm install(or equivalent) in the new worktree immediately after creation, and cleanup on removal. Without a dedicatedWorktreeCreatehook, there's no reliable way to initialize a worktree's environment before the agent starts touching files.
For real-world examples of this pattern in action, see:- claude-worktree-hooks — auto-setup for env files, dependencies, and deterministic dev ports
- Replacing My Custom Git Worktree Skill with Claude Code Hooks — custom branch naming and file copying on worktree creation
Reacted by Bradley Grainger, David Cosand, Todd Anglin, rimless-casualty, Sander De la Marche, Nathan Maves, Olivier VERMEULEN, Brian Liu and jacobcarpenter-logosWithout a dedicated
WorktreeCreatehook, there's no reliable way to initialize a worktree's environment before the agent starts touching files.Claude supports a
.worktreeincludefile that allows to do just that:- copy
.gitignored files to the new worktree. - symlink folders like
node_modulesto the new worktree. - etc.
Reacted by jacobcarpenter-logos- copy
We were just discussing this issue again today, and I happened to notice in the settings dialog of the Github Copliot App (not the CLI), it does mention support for a
.worktreeincludefile. I'm struggling to find online documentation that supports this, but seems worth trying.
A native implementation would benefit from treating a worktree as a managed resource with an explicit lifecycle rather than just running
git worktree add/remove.Something like:
creating -> initializing -> ready -> dirty/clean -> retiring -> removedwith receipts for branch, base SHA, path, setup hooks, and cleanup decision.
The safety rule I would strongly preserve: never automatically delete a dirty/unmerged worktree just because the agent thinks the task is done. Cleanup should require a proven clean/merged state or explicit user approval.
WorktreeCreate/WorktreeRemovehooks then fit naturally around the state transitions and can handle dependencies, ignored files, ports, etc.
Copilot CLI should be able to create and destroy git worktrees as part of its normal problem-solving workflow. When working on a task, Copilot could spin up a dedicated worktree, do the work in isolation, and clean it up when done. This would make it safer and cleaner to work on multiple tasks in parallel without risk of context or file conflicts between sessions.