claude-code - 💡(How to fix) Fix WorktreeCreate hook 'Hook cancelled' for worktree Agent when dispatched alongside a sibling Agent call in one message

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

When two or more Agent tool calls are issued in a single assistant message (a parallel/concurrent batch), the WorktreeCreate hook for any isolation: "worktree" Agent in that batch is killed with Hook cancelled — even when only one of the concurrent Agent calls actually creates a worktree. Dispatching the same worktree Agent alone in its own message succeeds every time.

The cancellation correlates with the presence of a sibling concurrent Agent call in the same message, not with the number of worktrees being created or with any git-level contention.

Root Cause

Concurrent Agent tool calls in a single message should each run their WorktreeCreate hook to completion. Hook invocations should not be cancelled merely because a sibling Agent call exists in the same batch.

Fix Action

Workaround

Dispatch worktree-isolated Agents one per message (never two Agent calls — worktree or otherwise — in the same message when one needs a worktree). This serializes throughput but avoids the cancellation entirely.

Code Example

WorktreeCreate hook failed: bash "$CLAUDE_PROJECT_DIR/.gitban/hooks/worktree-create.sh": Hook cancelled
RAW_BUFFERClick to expand / collapse

Summary

When two or more Agent tool calls are issued in a single assistant message (a parallel/concurrent batch), the WorktreeCreate hook for any isolation: "worktree" Agent in that batch is killed with Hook cancelled — even when only one of the concurrent Agent calls actually creates a worktree. Dispatching the same worktree Agent alone in its own message succeeds every time.

The cancellation correlates with the presence of a sibling concurrent Agent call in the same message, not with the number of worktrees being created or with any git-level contention.

Environment

  • Claude Code: 2.1.150
  • OS: Windows 10 (10.0.19045), git-bash hooks
  • git: 2.39.0.windows.1

Reproduction

  1. Configure a WorktreeCreate hook (any script that creates a worktree and echoes the path on stdout).
  2. In a single assistant message, issue two Agent tool calls:
    • one Agent(subagent_type: "<any>", isolation: "worktree")
    • one Agent(subagent_type: "<any>") with no worktree isolation
  3. Observe: the worktree Agent's hook fails with:
    WorktreeCreate hook failed: bash "$CLAUDE_PROJECT_DIR/.gitban/hooks/worktree-create.sh": Hook cancelled
    The non-worktree Agent launches fine.

Additional observations from a live multi-agent dispatcher:

  • 4 worktree Agents in one message -> all 4 hooks Hook cancelled.
  • 1 worktree Agent + 1 non-worktree Agent in one message -> the worktree hook is cancelled (so it is NOT about worktree count).
  • 1 worktree Agent alone in its own message -> succeeds every time.

Expected behavior

Concurrent Agent tool calls in a single message should each run their WorktreeCreate hook to completion. Hook invocations should not be cancelled merely because a sibling Agent call exists in the same batch.

Ruled out: VCS contention

The worktree-creation command is not the cause. On the affected environment, four concurrent worktree-creation invocations against the same repo all complete successfully (exit 0, all worktrees created), so this is not a git-level lock race on the worktree metadata. The cancellation originates in the Claude Code harness's handling of concurrent Agent spawns, before/around the hook process.

Side effect

A cancelled WorktreeCreate can leave an orphaned, git-registered + locked worktree directory on disk (.claude/worktrees/agent-<id>). On Windows both forced worktree removal and rm -rf hit Permission denied on the locked directory; deleting the branch plus pruning clears the git metadata but the directory persists. The harness should not leave partial worktree state behind when it cancels a hook.

Workaround

Dispatch worktree-isolated Agents one per message (never two Agent calls — worktree or otherwise — in the same message when one needs a worktree). This serializes throughput but avoids the cancellation entirely.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Concurrent Agent tool calls in a single message should each run their WorktreeCreate hook to completion. Hook invocations should not be cancelled merely because a sibling Agent call exists in the same batch.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING