claude-code - 💡(How to fix) Fix Stale background daemons from prior version cause ENOENT posix_spawn when launching agents after upgrade [1 comments, 2 participants]

What happened

After Homebrew upgraded the claude-code cask from 2.1.128 → 2.1.138, launching any new agent fails with:

ENOENT: no such file or directory, posix_spawn '/opt/homebrew/Caskroom/claude-code/2.1.128/claude'; respawning

Restarting the foreground claude process does NOT fix it.

Root cause

Long-lived background processes from the previous version survive the cask upgrade. The 2.1.128 Caskroom directory has been deleted by Homebrew, but these daemons remain running with the old absolute path in their argv[0]:

PID  ...  /opt/homebrew/Caskroom/claude-code/2.1.128/claude daemon run --origin transient --spawned-by {...}
PID  ...  /opt/homebrew/Caskroom/claude-code/2.1.128/claude --bg-pty-host /tmp/cc-daemon-.../spare/....pty.sock 200 50 -- ...
PID  ...  /opt/homebrew/Caskroom/claude-code/2.1.128/claude --bg-spare /tmp/cc-daemon-.../spare/....claim.sock

When a new agent is spawned, the daemon re-execs its own argv[0] (the deleted 2.1.128 path), so posix_spawn returns ENOENT and the "respawning" loop never recovers.

Workaround

pkill -f 'Caskroom/claude-code/2\.1\.128'
# then start a fresh `claude` session — daemon respawns from 2.1.138

Suggested fixes

• On daemon startup, resolve the binary via /opt/homebrew/bin/claude (or another stable path), not the versioned Caskroom path.
• Detect a missing argv[0] on respawn and exit cleanly so a new daemon can be started from the current binary, instead of looping.
• Have the foreground process check the daemon's binary path on connect and kill+respawn the daemon if it points to a deleted version.

Environment

• macOS (darwin 25.4.0)
• Installed via Homebrew Cask
• Affected versions observed: 2.1.128 daemons left over after upgrade to 2.1.138