claude-code - 💡(How to fix) Fix [BUG] Agent teammate panes spawn in different tmux session than parent process [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#55167Fetched 2026-05-01 05:44:30
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×4

Error Message

Error Messages/Logs

Root Cause

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.

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report
  • 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.

extent analysis

TL;DR

The teammate pane is being created in a different tmux session than the parent Claude Code process due to the TmuxBackend targeting the attached client instead of the parent's $TMUX, and a potential fix involves modifying the TmuxBackend to use the parent's $TMUX environment variable.

Guidance

  • Investigate the TmuxBackend code to determine how it selects the target session for spawning teammates, and consider modifying it to use the parent process's $TMUX environment variable.
  • Verify that the ~/.claude/teams/<team>/config.json file is correctly recording the teammate's tmuxPaneId and cwd, and use tmux list-panes -a to confirm the pane's placement.
  • Test the hypothesis by reattaching to the parent's session and verifying that the teammate pane is created in the correct session.
  • Consider implementing a fallback mechanism to handle cases where the parent's session has no attached client, to ensure the pane is still created in the correct session.

Example

No code example is provided as the issue does not include specific code snippets, but the fix is likely to involve modifying the TmuxBackend to use the parent's $TMUX environment variable.

Notes

The issue is likely related to #49184, and resolving this issue may also fix the focus-steal problem. The fix may require changes to the TmuxBackend code, and thorough testing is necessary to ensure the correct behavior in different scenarios.

Recommendation

Apply a workaround by modifying the TmuxBackend to use the parent's $TMUX environment variable, as this is likely to resolve the issue and fix the underlying problem.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Agent teammate panes spawn in different tmux session than parent process [1 participants]