[Bug]: Worktrees T3 creates for Claude threads ignore Claude Code's WorktreeCreate / WorktreeRemove hooks

[alexandercaley]

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 a git repo, add a project-level Claude Code WorktreeCreate hook in .claude/settings.json. Make it log its input, create the worktree (git worktree add …) and print the path. A SessionStart hook that logs too is useful for comparison.
2. Add the repo as a T3 project and start a thread on a Claude provider instance.
3. In the thread, have Claude create a worktree with its own EnterWorktree tool. → The WorktreeCreate hook runs, and Claude uses the path it returns.
4. In the same thread, call delegate_task with isolation: "worktree", or start a new thread in a new worktree from the UI. → The WorktreeCreate hook is not called. T3 creates ~/.t3/worktrees/<repo>/t3-<id> with plain git worktree add. The child's SessionStart hook does fire inside that worktree.

Expected behavior

T3 Code uses Claude Code's login and configuration (docs/user/providers-claude.md). So for Claude-backed threads, a worktree should be created and removed by the project's configured Claude Code WorktreeCreate / WorktreeRemove hooks, as Claude Code does. Claude Code runs a WorktreeCreate hook instead of git worktree add and uses the path it prints. Today, the same thread gets different worktrees depending on whether Claude or T3 creates them.

Actual behavior

T3 creates and removes worktrees itself, through GitVcsDriver.createWorktree / removeWorktree (git worktree add / remove); storage cleanup and PR review checkouts do the same. The configured hooks never run for T3-made worktrees.

runOnWorktreeCreate scripts don't solve this. They run after T3 has already created a plain git worktree at its own path, so they can't control where or how the checkout is made.

Example of a hook this breaks: a repo that needs sibling repos checked out next to it. The code refers to ../shared-lib and similar paths. The WorktreeCreate hook creates the main worktree and matching worktrees of each sibling in a parallel directory, so the relative paths resolve, and WorktreeRemove tears all of them down together. A T3-made worktree under ~/.t3/worktrees/<repo>/t3-<id> has no siblings beside it, so builds and tests in that thread fail, and nothing cleans up siblings on removal.

Impact

Major degradation or frequent failure (for any repo that depends on these hooks: T3 worktree isolation and new-worktree threads are unusable there).

Version or commit

T3 Code 0.1.2 (CLI service); behavior read against main @ 453bf01

Environment

macOS 26.2 (Apple Silicon), T3 CLI service, Claude Code 2.1.308 (claudeAgent provider)

Logs or stack traces

Hook log from the repro (one T3 thread; payloads trimmed):

01:00:58 SessionStart   {"cwd":"/private/tmp/t3-hooktest/repo", ...}                         # parent thread starts
01:01:01 WorktreeCreate {"cwd":"/private/tmp/t3-hooktest/repo", ...}                         # Claude EnterWorktree → hook runs, its path is used
01:01:06 SessionStart   {"cwd":"/Users/…/.t3/worktrees/repo/t3-8d562f36", ...}               # delegate_task isolation:"worktree" → NO WorktreeCreate; T3 used git directly

git worktree list afterwards:

/private/tmp/t3-hooktest/repo                    [master]
/private/tmp/t3-hooktest/wt-native               [wt-native]          # created by the hook
/Users/…/.t3/worktrees/repo/t3-8d562f36          [t3/reply-child-ok]  # created by T3, hook bypassed

Workaround

Avoid T3-made worktrees in these repos: ask Claude to use EnterWorktree or native subagent worktree isolation, which do run the hooks. This loses T3's worktree features (delegate_task worktree isolation, new-worktree threads, automatic cleanup).

Possible fix (suggestion only)

An opt-in per-project setting, for example worktreeCreation: "git" | "claudeHooks", with the default unchanged. When enabled for a Claude-backed thread, T3 runs the resolved WorktreeCreate / WorktreeRemove hooks (user, project and local settings, and enabled plugins) instead of git worktree add / remove. It binds the thread to the returned path and falls back to git when no hook is configured. Happy to discuss scope, or to move this to an Ideas discussion if you'd prefer, and to implement it if the direction is approved.

[alexandercaley]

Two smaller asks that would cover most of this without T3 having to run Claude's hooks. Both came out of trying to work around it with runOnWorktreeCreate.

1. t3 thread start --worktree-path <path>

t3_thread_launch already accepts workspaceStrategy: { type: "existing_worktree", worktreePath, branch }, but the CLI's launchWorkspaceStrategy only builds type: "worktree" from --worktree <base-ref>. A flag for an existing checkout would let a script create the worktree the way the repo needs (main repo plus siblings), then open a T3 thread bound to it:

make-sibling-worktrees feature-x    # however the repo needs it
t3 thread start --worktree-path ../worktrees/feature-x/repo --branch feature-x . "…"

Today only an agent already running in a T3 thread can do this, by calling t3_thread_launch itself.

2. A provider-agnostic worktree command, as an alternative to running Claude's hooks

If running the resolved Claude WorktreeCreate / WorktreeRemove hooks is too Claude-specific, a per-project command with the same contract would do the job. T3 runs it instead of git worktree add, passing the repo, branch and base ref (for example as JSON on stdin), and binds the thread to the absolute path it prints on stdout. A matching remove command runs instead of git worktree remove. A repo that already has a WorktreeCreate hook could point both at the same script. Because delegate_task isolation: "worktree" and t3_worktree_handoff go through the same createWorktree path, this would cover them too.

Why setup scripts can't stand in

• They run after git worktree add has already placed the checkout at <worktrees dir>/<repo>/<branch>. From there, ../sibling is a single directory shared by every branch of the repo.
• Nothing lets a script re-point the thread afterwards. t3_thread_update deliberately refuses workspace changes, and t3_worktree_handoff only creates a new worktree at T3's path.
• Nothing runs when a worktree is removed, so the siblings never get cleaned up.