claude-code - 💡(How to fix) Fix Re-attaching to existing session ENOENTs after Homebrew Cask upgrade (stale versioned worker path)

Summary

When Claude Code is installed via the Homebrew Cask and is upgraded while a session is running (or detached), re-attaching to that existing session fails repeatedly with:

[worker crashed (ENOENT: no such file or directory, posix_spawn '/opt/homebrew/Caskroom/claude-code/<old-version>/claude') — respawning…]

The session captures the absolute, versioned Caskroom path of the binary at session start. Homebrew Cask deletes the previous version's directory during brew upgrade, so the spawn path is invalid. The harness then enters a respawn loop that never recovers because nothing re-resolves the path.

Repro

1. brew install --cask claude-code (say, version 2.1.133)
2. Start a session: claude — leave it detached (Ctrl+Z) or running in a tmux pane.
3. brew upgrade --cask claude-code to e.g. 2.1.139. Homebrew removes /opt/homebrew/Caskroom/claude-code/2.1.133/.
4. Re-attach to the original session.

Expected: Worker respawns against the current binary (resolved via /opt/homebrew/bin/claude symlink). Actual: Endless ENOENT … posix_spawn '/opt/homebrew/Caskroom/claude-code/2.1.133/claude' — respawning…. Session is unusable.

Environment

• macOS Darwin 25.5.0 (arm64)
• Claude Code 2.1.139 currently installed (was 2.1.133 at session start)
• Install: Homebrew Cask (/opt/homebrew/Caskroom/claude-code/2.1.139/, symlinked from /opt/homebrew/bin/claude)

Suggested fix

On worker respawn, resolve the binary via /opt/homebrew/bin/claude (or $PATH lookup), not the versioned Caskroom path captured at session start. Alternatively, detect ENOENT on the stored path and fall back to a PATH lookup before giving up.

Workaround

Start a fresh session (or claude -c to resume the conversation under the new binary). The old session cannot be recovered.