feat(worktree name): use jira ticket name in worktree name

[splisson-cn]

As a muzzle user
When starting a session with claude
I would like claude to ask for the optional session name prefix
AND muzzle should use it to prefix the worktree folder name so it's easy to see which worktree is related to which work session

[frits-v]

Thanks for the feature request! Triaged this and wanted to share some findings on feasibility.

The core challenge

Muzzle's SessionStart hook runs before the user can interact with the session. The lifecycle in VS Code (Claude Code extension) is:

1. User opens chat panel → session spawns
2. SessionStart hook fires → worktree created as .worktrees/<8-char-hash>
3. Only now can the user type anything

So there's no point in the flow where muzzle could prompt for a session name prefix before creating the worktree. This applies to both VS Code and terminal usage — hooks are non-interactive.

We also looked at hooking into /rename (which would be a natural fit), but it doesn't fire any hook event that muzzle could listen to.

What is feasible: post-hoc labeling

Instead of naming at creation time, we could add a muzzle-label binary that renames the branch after the session starts:

1. Session starts → worktree created normally (.worktrees/de5b7072, branch wt/de5b7072)
2. User tells Claude what they're working on, or says "label this session PROJ-123"
3. Claude runs muzzle-label PROJ-123, which:
   • Renames the branch: wt/de5b7072 → wt/PROJ-123-de5b7072
   • Updates the spec file with the new branch name
   • Optionally creates a symlink .worktrees/PROJ-123 → de5b7072

The worktree directory stays as the hash (renaming it breaks git worktree internal metadata in .git/worktrees/), but the branch name becomes human-readable — which is what shows up in git log, PRs, and IDE status bars.

No new Claude Code hook events needed — it's just a Bash tool call.

Questions for you

1. Would the branch rename approach satisfy your use case, or do you specifically need the directory name to change?
2. Would you expect Claude to auto-detect the ticket from context (e.g., if you mention "PROJ-123"), or would an explicit command be fine?

Labeling this needs-design for now — happy to move forward once we align on the UX.

[splisson-cn]

1. That would satisfy my use case
2. No it could be confusing or picking the wrong one because I mentioned it.

[frits-v]

Thanks for confirming @splisson-cn! Based on your feedback (branch rename is fine, explicit over auto-detect), here's the design we're going with:

Design: Deferred Worktree Creation with Optional Label

New config key in ~/.config/muzzle/config:

[worktree]
defer = true

How it works

When defer = true, SessionStart skips worktree creation and instead injects a prompt instructing Claude to ask for a session label:

1. SessionStart fires — no worktree created yet
2. Claude asks: "What should I name this session? (e.g., PROJ-123, or skip)"
3. You reply PROJ-123 (or skip for auto-naming)
4. Claude runs ensure-worktree <repo> --label PROJ-123
5. Worktree created:
   • Directory: .worktrees/PROJ-123-bc595c0c (visible in VS Code file tree)
   • Branch: wt/PROJ-123-bc595c0c (visible in git log, PRs, IDE status bar)

The <short_id> suffix (bc595c0c) keeps names unique across sessions even if you reuse the same label.

When defer = false (the default), current behavior is unchanged — worktree created immediately as .worktrees/<short_id> with branch wt/<short_id>.

What this means for you

• Opt-in: Set defer = true in your muzzle config to get the prompt flow
• No auto-detection: Claude asks explicitly, no guessing from context
• VS Code friendly: Directory names show the label in the file tree
• Cleanup works: wt/* branch cleanup already handles labeled branches

What stays the same

• No new binaries — extends the existing ensure-worktree
• Spec file format unchanged
• Users who don't set defer = true see zero behavior change

Does this look good to you? Any concerns before we implement?

[splisson-cn]

Sounds good to me

…

On Wed, Mar 25, 2026 at 2:51 PM Frits ***@***.***> wrote: *frits-v* left a comment (frits-v/muzzle#23) <#23 (comment)> Thanks for confirming @splisson-cn <https://github.com/splisson-cn>! Based on your feedback (branch rename is fine, explicit over auto-detect), here's the design we're going with: Design: Deferred Worktree Creation with Optional Label New config key in ~/.config/muzzle/config: [worktree]defer = true How it works When defer = true, SessionStart skips worktree creation and instead injects a prompt instructing Claude to ask for a session label: 1. *SessionStart* fires — no worktree created yet 2. Claude asks: *"What should I name this session? (e.g., PROJ-123, or skip)"* 3. You reply PROJ-123 (or skip for auto-naming) 4. Claude runs ensure-worktree <repo> --label PROJ-123 5. Worktree created: - *Directory:* .worktrees/PROJ-123-bc595c0c (visible in VS Code file tree) - *Branch:* wt/PROJ-123-bc595c0c (visible in git log, PRs, IDE status bar) The <short_id> suffix (bc595c0c) keeps names unique across sessions even if you reuse the same label. When defer = false (the default), current behavior is unchanged — worktree created immediately as .worktrees/<short_id> with branch wt/<short_id>. What this means for you - *Opt-in:* Set defer = true in your muzzle config to get the prompt flow - *No auto-detection:* Claude asks explicitly, no guessing from context - *VS Code friendly:* Directory names show the label in the file tree - *Cleanup works:* wt/* branch cleanup already handles labeled branches What stays the same - No new binaries — extends the existing ensure-worktree - Spec file format unchanged - Users who don't set defer = true see zero behavior change Does this look good to you? Any concerns before we implement? — Reply to this email directly, view it on GitHub <#23?email_source=notifications&email_token=AS6YVCGFGQMNSSIULYI26YD4SRIGZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJTGAYDMNJQGQYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4130065040>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS6YVCCJTECP3ZXGYCAZJML4SRIGZAVCNFSM6AAAAACWWWBQP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMZQGA3DKMBUGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>