[BUG] Agent cleanup can non-deterministically kill its own tmux session, losing all work

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?

Description

When running multi-agent workflows (e.g., BMAD code-review skill that spawns subagents), the
LLM-driven cleanup phase can non-deterministically issue tmux kill-pane / tmux kill-session commands
that destroy the host session itself, not just the subagent panes. This results in complete loss of
the current session's work.

# Steps to Reproduce

1. Run Claude Code v2.1.63 inside a tmux session
2. Execute a multi-agent workflow (e.g., a BMAD code-review skill that spawns agents in tmux panes)
3. Wait for the workflow to complete and agents to be cleaned up

Expected: Subagent panes are cleaned up silently (as observed in a prior run 2 hours earlier with
the same version and workflow)

Actual (intermittent): Claude issues tmux kill-pane commands via the Bash tool for each subagent
pane, triggering permission prompts for each one. It then kills its own tmux pane/session,
terminating the entire Claude Code session and losing all work.

# Key Details

• Version: 2.1.63
• Not version-dependent: The identical workflow with the same version ran correctly ~2 hours prior

without any tmux kill prompts

• Non-deterministic: The LLM decides at runtime how to clean up agent panes. Sometimes it does it

silently/correctly; sometimes it issues explicit tmux kill commands via Bash

• Self-termination: The agent does not distinguish between subagent panes and its own hosting pane,

leading to self-termination

# Root Cause Analysis

The agent cleanup path is not deterministic — it's driven by LLM reasoning, which means the cleanup
strategy can vary between runs. There is no hard constraint at the tool/sandbox level preventing
Claude from issuing a tmux kill command that targets its own session.

# Suggested Fix

Consider one or more of:

1. Hard block at the Bash tool level on commands that would kill the agent's own tmux session/pane

(detect own $TMUX_PANE / session and reject)

1. Deterministic (non-LLM) agent cleanup — when subagents finish, clean up their panes via internal

process management, not via LLM-issued Bash commands

1. At minimum, never prompt the user for permission to kill tmux panes during agent cleanup — the

appearance of these prompts is a signal that cleanup went off the rails

# Impact

• Data loss: Entire session history and in-progress work is destroyed
• Unpredictable: Cannot be prevented by the user since it's non-deterministic
• Trust erosion: Users cannot rely on long-running multi-agent workflows if the agent can randomly

self-terminate

What Should Happen?

Expected: Subagent panes are cleaned up silently (as observed in a prior run 2 hours earlier with
the same version and workflow)

Actual (intermittent): Claude issues tmux kill-pane commands via the Bash tool for each subagent
pane, triggering permission prompts for each one. It then kills its own tmux pane/session,
terminating the entire Claude Code session and losing all work.

Error Messages/Logs

Steps to Reproduce

Run Claude Code v2.1.63 inside a tmux session
Execute a multi-agent workflow
Wait for the workflow to complete and agents to be cleaned up
Expected: Subagent panes are cleaned up silently (as observed in a prior run 2 hours earlier with
the same version and workflow)

Actual (intermittent): Claude issues tmux kill-pane commands via the Bash tool for each subagent
pane, triggering permission prompts for each one. It then kills its own tmux pane/session,
terminating the entire Claude Code session and losing all work.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

v2.1.63

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

iTerm2

Additional Information

_No response_