[BUG] Agent teammate panes spawn in different tmux session than parent process

Resolved 💬 1 comment Opened May 1, 2026 by dialalpha Closed May 3, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

When the parent Claude Code process is running inside a tmux session and uses Agent Teams (the Agent tool with team_name and run_in_background: true) to spawn a teammate, the teammate's tmux pane can land in a completely different tmux session than the parent — not just an unfocused pane in the same session.

This appears related to #49184 (focus-steal on spawn) — likely the same underlying choice in TmuxBackend — but produces a stronger symptom: the pane is not merely unfocused, it's in the wrong session entirely. The user has no visual signal that a teammate was spawned, the team-lead has no addressable counterpart in its own view, and the user can be looking at an unrelated workspace while autonomous work proceeds invisibly elsewhere.

Hypothesis: TmuxBackend selects the spawn target based on tmux-client/active-pane state (e.g., "currently attached client") rather than the parent process's $TMUX env var. When the parent's session has no live attached client (terminal closed, detached, or its client has died while the session persists), the backend falls through to whichever client is live — even if that client is serving an unrelated session.

Concrete repro

  • Two tmux sessions exist, call them session-a and session-b (created via tmux new-session -s ... in separate terminals).
  • Team lead Claude was running inside session-a. It spawned a teammate as part of a normal Agent Teams workflow.
  • ~/.claude/teams/<team-name>/config.json records the teammate's tmuxPaneId as "%6" and cwd as the path of session-a.
  • tmux list-panes -a shows pane %6 is in session-b, not session-a.
  • tmux list-clients at the time showed only one live client, attached to session-bsession-a's terminal client had died (session persisted, but no client was serving it). Strongly suggests the backend picked the live client's session as the spawn target.

What Should Happen?

The teammate pane should be created in the same tmux session as the parent Claude Code process — determined by the parent's $TMUX, not by which client is currently attached. If the parent's session has no attached client, the pane should still land there; it simply isn't visible until the user reattaches.

Steps to Reproduce

  1. Create two tmux sessions in separate terminals: tmux new-session -s a and tmux new-session -s b.
  2. In a, start Claude Code and kick off any workflow that uses Agent Teams.
  3. Close a's terminal (or tmux detach). Session a persists; its client dies.
  4. Reattach to b so b is the only live tmux client.
  5. The team lead in session a (still running) spawns its next teammate.
  6. Observe: the new pane appears in session b. Confirm with tmux list-panes -a and ~/.claude/teams/<team>/config.json.

Error Messages/Logs

None — silent misplacement.

Claude Model

claude-opus-4-7

Is this a regression?

Unknown — multi-session setups have not worked correctly across versions tested.

Last Working Version

n/a

Claude Code Version

2.1.123

Platform

Anthropic API

Operating System

Windows 11 on ARM

Terminal/Shell

psmux (tmux-compatible) running under Git Bash

Additional Information

Likely the same root cause as #49184 — both behaviors are explained by "TmuxBackend targets the attached client instead of the parent's $TMUX." A fix that consults the parent process's $TMUX should resolve both.

Convenient evidence: ~/.claude/teams/<team>/config.json records each member's tmuxPaneId, which can be matched against tmux list-panes -a to confirm placement after the fact.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗