WorktreeCreate hook causes indefinite hang regardless of hook command

Status Closed — not planned
Reported on v2.1.87
Maintainer reply None cached
Activity 4 comments · opened Mar 31, 2026 · closed Jun 2, 2026

Bug Description

claude -w hangs indefinitely when any WorktreeCreate hook is configured in project settings. The hook script itself completes successfully (confirmed via debug logging to a file), but Claude Code never proceeds after the hook returns.

Even a trivial hook like echo ok < /dev/null reproduces the hang. Removing the WorktreeCreate hook config resolves the hang immediately.

Reproduction Steps

  1. Add to .claude/settings.local.json:
{
  "hooks": {
    "WorktreeCreate": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo ok < /dev/null"
          }
        ]
      }
    ]
  }
}
  1. Run claude -w
  2. Claude Code hangs indefinitely

Expected Behavior

The hook should run and Claude Code should proceed with the worktree session.

Actual Behavior

Claude Code hangs indefinitely after the hook completes. The hook command itself finishes (verified by writing debug output to /tmp), but Claude Code never moves on.

Debugging Done

  • Confirmed the hook script runs to completion via file-based debug logging
  • Tested with the actual setup script, a minimal cat > /dev/null; echo ok, and echo ok < /dev/null -- all hang
  • Removing the WorktreeCreate hook config entirely resolves the hang
  • No other hook types (PreToolUse, PostToolUse, SessionStart) exhibit this behavior

Workaround

Use a SessionStart hook that detects if it's running inside a worktree:

"SessionStart": [
  {
    "hooks": [
      {
        "type": "command",
        "command": "/path/to/worktree-setup.sh < /dev/null"
      }
    ]
  }
]

Environment

  • Claude Code version: 2.1.87
  • OS: macOS (Darwin 25.3.0)
  • Shell: bash

View original on GitHub ↗

4 Comments

brandonjpetersen · 5 months ago

Reproducing this on Windows 11 with Claude Code 2.1.126 — same exact behavior, so the bug isn't macOS-specific. Worth broadening the platform label.

Environment

  • Claude Code: 2.1.126
  • OS: Windows 11 Pro 10.0.26200
  • Shell launching claude: PowerShell 7
  • Hook shell: Git for Windows bash

Repro

A real-world WorktreeCreate hook that does roughly:

  1. Parse cwd and name from the JSON stdin payload.
  2. git worktree add "$CWD/.claude/worktrees/$name" -b "worktree-$name" origin/HEAD.
  3. npm ci in the Angular sub-project.
  4. dotnet restore in the .NET sub-project.
  5. Install project-managed git hooks into the new worktree.
  6. echo "$WORKTREE_PATH" to stdout, exit 0.

Invoked as: `claude --worktree=issue-285`

Observed

  1. Hook script runs to completion. Verified via the script's own log file:

``
[...] running npm ci in gainingsteam-app...
[...] npm ci succeeded
[...] running dotnet restore in api/...
[...] dotnet restore succeeded
[...] installed git hooks
[...] setup complete
``

  1. Worktree directory exists on disk and is fully populated.
  2. Hook prints the worktree path to stdout and exits 0.
  3. Claude Code hangs indefinitely — UI never appears, no further output.

Process snapshot during hang

Only the parent `claude.exe` is running. No child processes — bash, node, dotnet, npm have all exited cleanly:

ProcessId ParentProcessId Name       Cmd
--------- --------------- ----       ---
   163896           61356 claude.exe "C:\Users\<user>\.local\bin\claude.exe" --worktree=issue-285

This rules out the common "child process inheriting stdio handles keeps the pipe open" theory on Windows — there is genuinely nothing left to wait on.

Workaround that works on Windows

Same as the reporter's: `cd directly into the already-set-up worktree and run claude (no --worktree` flag). Skips whatever post-hook step is hanging.

Happy to provide additional diagnostics if useful — process traces, debug logs, a minimized hook script, etc.

github-actions[bot] · 4 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

mikeschinkel · 4 months ago

This was automatically closed because being _"inactive for too long"_; but was it ever resolved?

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.