WorktreeCreate hook 'Hook cancelled' for worktree Agent when dispatched alongside a sibling Agent call in one message

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

1. 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.