claude-code - 💡(How to fix) Fix [BUG] Worktree creation hangs indefinitely: spawned 'git merge --ff-only' blocked reading stdin (unix socket never written to / closed) [2 comments, 2 participants]

Summary

Claude Code desktop on macOS hangs indefinitely when creating a new worktree. The hung child process is git merge --ff-only refs/remotes/origin/main, blocked in read() on a Unix socket assigned as its stdin — Claude Code opens that socket but never writes to or closes it, so the read never returns.

The UI sits at the "creating worktree..." state forever. Subsequent attempts queue behind the first, never starting.

Environment

• macOS 26.4 (build 25E246), Apple Silicon
• Claude.app version 1.3883.0
• Apple Git: git version 2.50.1 (Apple Git-155) (from /Applications/Xcode.app/Contents/Developer/usr/bin/git, the default /usr/bin/git shim)
• Repository: large monorepo (~30 pack files, ~5,000 tracked paths, ~40 existing worktrees, shallow clone)

Reproduction

1. Have a moderately large repo loaded in Claude Code desktop on macOS.
2. Trigger a new worktree creation (e.g., start a new session that requires one).
3. Observe the UI hang. Optionally trigger another worktree — it queues behind the first.

Diagnostic evidence

The hung process always has these characteristics:

ps -eo pid,ppid,etime,pcpu,command | grep "git merge --ff-only"
# 16100   682   40:31   0.0  /Applications/Xcode.app/Contents/Developer/usr/bin/git \
#                            -c core.hooksPath=/dev/null \
#                            -c safe.directory=* \
#                            merge --ff-only refs/remotes/origin/main
#
# (parent 682 = /Applications/Claude.app/Contents/MacOS/Claude)

Stuck at 0% CPU. Stack trace via sample <pid>:

read_in_full  (in git)
  xread  (in git)
    read  (in libsystem_kernel.dylib)

File descriptor 0 (stdin) is a Unix socket, not /dev/null:

lsof -p 16100 | awk '$4 == \"0u\"'
# git  16100  jasonbarnett  0u  unix 0x7f8e4e40e2780357  0t0  ->0xf15e62ace7be3974

The peer end of that socket is owned by Claude.app, but nothing is ever written to it and it's never closed.

This holds the worktree's .git/worktrees/<name>/index.lock, blocking subsequent git operations against that worktree.

Workaround

Killing the hung process unblocks Claude Code's internal queue immediately:

pkill -9 -f \"Xcode.app.*git merge --ff-only\"

Within ~2 seconds, Claude Code spawns the next pipeline step (git checkout HEAD -- . :(exclude).claude), which completes normally in <5 seconds and the worktree is fully populated.

Suspected cause

It looks like Claude Code attaches a pipe for git's stdin (presumably intended to feed input to a future code path) but the current code path never writes to or closes it. merge --ff-only doesn't normally need stdin input, so the simplest fix is probably to attach /dev/null (or close stdin) when spawning the subprocess.

Adjacent / related issues (not duplicates)

• #42752 — --worktree flag hangs when WorktreeCreate hooks attached (different cause: hook-side)
• #32091 — claude --worktree hangs on Linux (different platform, possibly different cause)
• #53011 — /rewind hangs the CLI on macOS (might share spawn / stdin handling)
• #40968, #48405 — worktree state-management issues, unrelated cause

Severity

Blocking for any workflow that creates new worktrees on macOS. Repro is reliable and gets worse as the repo grows (auto-maintenance triggers compound the queue-up effect).