[BUG] TeamDelete returns success on a team with shutdown-pending teammate, orphaning a tmux pane

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?

TeamDelete returns success: true on a team whose member was sent shutdown_request but has not yet emitted shutdown_approved. The teammate is still mid-shutdown when the team_dir is wiped under it. The teammate's claude process eventually exits when it can't read its now-missing config files / sockets, but the bash wrapper that launched claude stays alive at an interactive prompt and holds the tmux pane open indefinitely. SIGTERM to that bash is ignored — only SIGKILL closes it.

The existing "Cannot cleanup team with N active member(s)" rejection correctly refuses a busy teammate (one mid-tool-call), but the same check accepts a shutdown-pending teammate. Sending shutdown_request apparently flips the member to "shutting-down", which the check treats as "no longer active".

What Should Happen?

TeamDelete should refuse with "Cannot cleanup team with 1 active member(s): probe" (same shape as the existing rejection for tool-busy members), because probe has not yet emitted shutdown_approved.

If the user genuinely needs to force-delete a wedged team (teammate that never replies to shutdown_request), that should be a separate explicit flag — not the default behaviour.

Error Messages/Logs

Polled state via `tmux list-panes`, `ps -ax -o pid,etime,command`, and `ls ~/.claude/teams/race-test/`:


[t+0s ]  team_dir=absent  tmux_panes=2  probe_pid=ALIVE
[t+2s ]  team_dir=absent  tmux_panes=2  probe_pid=ALIVE
[t+7s ]  team_dir=absent  tmux_panes=2  probe_pid=ALIVE
[t+15s]  team_dir=absent  tmux_panes=2  probe_pid=ALIVE
[t+30s]  team_dir=absent  tmux_panes=2  probe_pid=ALIVE
[t+60s]  team_dir=absent  tmux_panes=2  probe_pid=ALIVE


`TeamDelete` response that should not have succeeded:


{"success": true, "message": "Cleaned up directories and worktrees for team \"race-test\"", "team_name": "race-test"}


Compare with the correct rejection that fires for a tool-busy teammate (no `shutdown_request` sent, teammate mid-`Bash sleep 60`):


{"success": false, "message": "Cannot cleanup team with 1 active member(s): probe. Use requestShutdown to gracefully terminate teammates first.", "team_name": "race-test"}


Same probe, same harness — only difference is whether `shutdown_request` was sent first.

Steps to Reproduce

1. Create a fresh team:

``
TeamCreate({ team_name: "race-test" })
``

1. Spawn a teammate that idles immediately:

``
Agent({
team_name: "race-test",
name: "probe",
subagent_type: "general-purpose",
prompt: "FIRST ACTION: ToolSearch select:SendMessage. Then SendMessage to team-lead 'ack'. Then go idle. When you receive {type: shutdown_request}, reply with shutdown_response."
})
``

1. Wait ~15 seconds for the teammate to boot and ack. Confirm the teammate's claude process is alive via ps -ax -o pid,command | grep agent-id.

1. Send shutdown_request and IMMEDIATELY call TeamDelete in the same turn (no wait):

``
SendMessage({ to: "probe", message: { type: "shutdown_request" } })
TeamDelete()
``

1. Observe TeamDelete returns success: true and ~/.claude/teams/race-test/ is wiped. Then poll the teammate's claude PID — it stays alive for at least 60 seconds, and the orphan tmux pane never closes on its own.

1. Cleanup: kill -9 <bash-pid-inside-the-orphan-pane> is the only reliable way to free the pane. SIGTERM is ignored.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.126

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This is one of three related bugs in the Agent Teams teardown path (filed separately per the preflight checklist):

• This issue (Bug 1): TeamDelete proceeds despite an unanswered shutdown_request.
• Related Bug 2: shutdown_approved's pane-close handler is non-deterministic — same setup produces clean close in some runs and orphan pane in others.
• Related Bug 3: Orchestrator lead context never auto-releases after teammate exits — sticky status bar + blocked TeamCreate.

Even if Bug 1 is fixed, Bug 2 means orphans can still happen on the well-formed teardown path.