[BUG] Agent Teams: tmux teammate panes spawn dead (status 127) after brew upgrade — #48889 fix does not cover long-lived interactive sessions (repro on 2.1.206 → 2.1.207)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

With experimental Agent Teams (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, --teammate-mode=tmux), the parent session embeds its own fully-resolved, version-pinned executable path into every teammate pane's spawn command. After brew upgrade replaces the Homebrew cask's version directory, the long-running parent keeps working (its deleted binary's inode stays alive), but every teammate spawned afterwards execs the now-deleted path and dies instantly — tmux shows Pane is dead (status 127).

Worse, the parent never learns the pane died: it lists the never-started teammates as running and waits for their reports indefinitely — the failure is completely silent in the parent UI.

#48889 (same root cause) was closed as fixed in v2.1.142, where the fix was described as: the daemon detects its own binary was deleted/replaced and exits cleanly so the next invocation uses the new version. That fix does not cover this scenario: an interactive parent session never self-exits (and shouldn't — it would destroy hours of session state), so it keeps handing the stale path to every new teammate. Reproduced on 2.1.206 → 2.1.207, far past the fix version.

What Should Happen?

Teammate spawning survives an in-place upgrade — e.g. spawn via the stable /opt/homebrew/bin/claude symlink (or claude from PATH) instead of the resolved execPath, or re-resolve/fall back when the embedded path no longer exists. Suggested:

1. Spawn teammates via a stable launcher path (Homebrew shim / ~/.local/bin/claude) or PATH resolution rather than the version-pinned resolved execPath; and/or
2. At spawn time, stat the embedded path and re-resolve from PATH if missing; and
3. Surface teammate pane death (non-zero exit / dead pane) to the parent instead of leaving the teammate listed as running.

Error Messages/Logs

# Visible in the teammate pane before death:
env: /opt/homebrew/Caskroom/claude-code@latest/2.1.206/claude: No such file or directory

# Dead pane's start command (tmux list-panes -F '#{pane_dead_status} #{pane_start_command}', paths lightly redacted):
dead_status=127
cd ~/codes/<project> && env CLAUDECODE=1 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 \
  CLAUDE_CODE_SUBAGENT_MODEL='opus[1m]' \
  /opt/homebrew/Caskroom/claude-code@latest/2.1.206/claude \
  --agent-id verify-backend@session-<id> --agent-name verify-backend \
  --team-name session-<id> --parent-session-id <uuid> --agent-type claude \
  --dangerously-skip-permissions --effort max --chrome --model 'claude-opus-4-8[1m]'

# Caskroom after the upgrade (the embedded path's directory is gone):
$ ls /opt/homebrew/Caskroom/claude-code@latest/
2.1.207

Steps to Reproduce

1. Install via brew install --cask claude-code@latest, start a Claude Code session with Agent Teams + --teammate-mode=tmux inside a tmux session, and leave it running.
2. While it runs: brew upgrade claude-code@latest (Homebrew deletes the old /opt/homebrew/Caskroom/claude-code@latest/<oldver>/ directory).
3. Have the parent spawn teammates.
4. Every teammate pane dies immediately with Pane is dead (status 127); the parent keeps showing the teammates as running.

Observed timeline: parent session started Jul 10 (resolved 2.1.206) → brew upgrade Jul 11 16:57 (2.1.206 dir deleted) → teammates spawned Jul 13 all dead with 127.

Claude Model

Other (failure occurs at process spawn, before any model is involved; the dying teammates were launched with --model claude-opus-4-8[1m])

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unclear — #48889 (same root cause) was closed as fixed in v2.1.142, but the fix (daemon self-exit on deleted binary) appears never to have covered long-lived interactive parents; reproduced on 2.1.206 → 2.1.207.

Claude Code Version

2.1.206 (Claude Code) — long-running parent; cask upgraded to 2.1.207 (Claude Code). Installed via Homebrew cask claude-code@latest.

Platform

Anthropic API

Operating System

macOS (26.5.2, arm64)

Terminal/Shell

VS Code integrated terminal (running tmux 3.6b — teammate panes are tmux panes, so the bug is terminal-emulator-independent)

Additional Information

Still present in 2.1.207: a teammate spawned by a fresh 2.1.207 parent embeds /opt/homebrew/Caskroom/claude-code@latest/2.1.207/claude — so the trap re-arms on every upgrade.

Relationship to existing issues:

• #48889 — closed completed, fixed in v2.1.142 via daemon self-exit on deleted binary. Interactive tmux-teammate parents never self-exit, so this path is uncovered (or regressed).
• #58560 — closed duplicate; same ENOENT on claude-code@latest/<ver>/claude via FleetView dispatch.
• #47253 — closed duplicate; native-installer analog (auto-updater deletes versioned dirs while sessions run).

Workaround (recovers a live session without restarting):

# make the stale embedded path resolve to the new version
ln -s <newver> /opt/homebrew/Caskroom/claude-code@latest/<oldver>
# replay each dead pane's original spawn command
tmux respawn-pane -t <dead-pane-id>

The respawned teammates rejoin the team and pick up their tasks; patch-level parent/child version skew (2.1.206 parent, 2.1.207 teammates) worked without issues.