[FEATURE] Add Windows Terminal as a split-pane backend for agent teams (teammateMode)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Windows Terminal users cannot use split-pane mode for agent teams. The current teammateMode setting only supports tmux and iTerm2 as backends. Windows Terminal users are forced to either:

1. Use in-process mode — losing all multi-pane visibility benefits
2. Install WSL + tmux — adding an entire Linux subsystem just for pane splitting
3. Use workaround scripts that attempt to bridge the gap via hooks (fragile, unsupported)

Proposed Solution

Add "windows-terminal" as a valid teammateMode backend, with auto-detection support.

Detection

Windows Terminal sets the WT_SESSION environment variable when running inside it:

// Detection: check for WT_SESSION env var
if (process.env.WT_SESSION) {
  // Running inside Windows Terminal
}

Additionally, wt.exe is available on PATH when Windows Terminal is installed, which can be checked as a fallback.

CLI Command Mapping

Windows Terminal's wt.exe CLI provides direct equivalents for all operations the tmux backend needs:

| Operation | tmux | Windows Terminal (wt.exe) |
|-----------|------|-----------------------------|
| Split vertically (side by side) | tmux split-window -h -- cmd | wt -w 0 split-pane -V -- cmd |
| Split horizontally (top/bottom) | tmux split-window -v -- cmd | wt -w 0 split-pane -H -- cmd |
| Set working directory | -c /path | -d /path |
| Set pane title | N/A (via printf) | --title "Agent Name" |
| Control pane size | N/A | -s 0.5 (50% of parent) |
| Target current window | Implicit (via $TMUX) | -w 0 (current window) |
| Pass environment vars | env VAR=val cmd | Set before wt invocation or via cmd /c "set VAR=val && cmd" |

Spawning a Teammate Pane

wt -w 0 split-pane -V -d "C:\project" --title "researcher" -- cmd /c "set CLAUDE_CODE_TEAM_NAME=my-team && set CLAUDE_CODE_AGENT_NAME=researcher && claude"

Or via PowerShell:

wt -w 0 split-pane -V -d "C:\project" --title "researcher" -- powershell.exe -Command {
    $env:CLAUDE_CODE_TEAM_NAME = 'my-team'
    $env:CLAUDE_CODE_AGENT_NAME = 'researcher'
    claude
}

Auto-Detection Priority

Update the auto-detection chain:

Current:  iTerm2 → tmux → in-process
Proposed: iTerm2 → tmux → windows-terminal → in-process

// Pseudocode for auto-detection
if (process.env.ITERM_SESSION_ID) return 'iterm2';
if (process.env.TMUX) return 'tmux';
if (process.env.WT_SESSION) return 'windows-terminal';  // NEW
return 'in-process';

Known Limitations

Windows Terminal's CLI has some gaps compared to tmux:

| Capability | tmux | Windows Terminal | Workaround |

| List panes | tmux list-panes | No equivalent | Track internally |
| Get pane ID | #{pane_id} | No env var | Use title-based tracking |
| Focus specific pane | tmux select-pane -t N | wt -w 0 move-focus --direction {up\|down\|left\|right} | Direction-based navigation |
| Send keys to pane | tmux send-keys | No equivalent | Use file-based IPC (inbox files) |

The lack of pane IDs means the backend would need to track panes internally (e.g., by title or creation order) rather than using terminal-native IDs. This is the same challenge WezTerm faces and is solvable with an internal mapping table.

Alternative Solutions

• WSL + tmux: Works but requires installing an entire Linux subsystem — heavyweight and unnecessary given WT's native CLI
• In-process mode: Functional but loses the primary benefit of agent teams: visual parallel work observation
• Hooks-based workarounds: I built a working prototype using PowerShell scripts + wt split-pane that creates proper split panes, but it cannot integrate with the native spawn backend because hooks can only block/allow tool calls, not redirect the spawn mechanism. A native backend is needed.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

As a Windows developer using Claude Code agent teams, I want each teammate to appear in its own Windows Terminal split pane so I can observe all agents working simultaneously — the same experience macOS/Linux users get with tmux.

Additional Context

Environment

• Claude Code version: 2.1.x (Opus 4.6)
• OS: Windows 11
• Terminal: Windows Terminal (default)
• Shell: PowerShell / cmd.exe

Related Issues

• #23574 — WezTerm split-pane backend (same motivation, different terminal)
• #24122 — Zellij split-pane support
• #24189 — Ghostty split-pane support (blocked on upstream API)
• #23572 — tmux/iTerm2 silent fallback bug
• #5723 — General Windows Terminal support (closed as duplicate of broader Windows issues — this issue is specifically about agent teams teammateMode)

Additional Context

Working Prototype

I have built a working prototype of this integration using PowerShell scripts that:

1. Launch a lead agent in the current WT pane
2. Use wt -w 0 split-pane to create teammate panes
3. Bridge to the native team protocol via environment variables (CLAUDE_CODE_TEAM_NAME, CLAUDE_CODE_AGENT_ID, CLAUDE_CODE_AGENT_NAME)
4. Register agents in ~/.claude/teams/{team}/config.json

The scripts work end-to-end when invoked manually, but cannot integrate with the internal Task tool's spawn mechanism because there is no hookable backend interface. A native windows-terminal backend would solve this cleanly.

Disclosure: AI-Assisted Issue

This issue was drafted by Claude Code (Opus 4.6) during an agent teams session where I was researching how to make the teams feature work with Windows Terminal split panes. The research, CLI command mapping, and technical analysis were produced by Claude Code's experimental agent teams feature — which, ironically, is the feature this issue is requesting better support for.

I was unable to find an explicit policy in this repository regarding AI-generated issues (there is no CONTRIBUTING.md or issue policy document). If AI-generated issues are not welcome here, I understand and apologize. However, I want to submit this regardless because:

• This is a real problem faced by a real user. I (the human filing this issue) actively tried to build a Windows Terminal integration for agent teams and hit the fundamental limitation described above.
• I have reviewed and verified the content. I read the full draft, confirmed the technical details (CLI commands, env vars, limitations), and vouch for its accuracy based on my own experimentation.
• The prototype scripts exist and work. The gap described (no hookable backend interface) is something I encountered firsthand, not a hypothetical.

The human author (which is me and I don't know how to confirm that this is actually a human typing so im just typing this to show that I am human since no AI would just ramble about nothing when trying to confirm its humanity like I am doing now (or would it?) ) reviewed and approved this issue before submission.