Split-pane agent teams blocked on Windows by isTTY gate overriding teammateMode: "tmux"

Summary

On Windows, setting "teammateMode": "tmux" in settings.json is silently ignored because process.stdout.isTTY is always falsy in the Claude Code Bun SFE binary. This forces isInProcessEnabled() to return true unconditionally, making split-pane agent teams impossible on Windows — even when a working tmux-compatible backend (psmux) is available and teammateMode explicitly requests it.

Environment

• OS: Windows 10 Home 10.0.19045
• Claude Code: Latest (Bun SFE binary)
• Terminals tested: Git Bash (mintty), cmd.exe, winpty — all fail identically

Root Cause

The startup code sets isInteractive based on:

let D = $ || A || L || !process.stdout.isTTY;
setIsInteractive(!D);

In the Bun SFE on Windows, process.stdout.isTTY is undefined regardless of the terminal (cmd.exe, mintty, winpty). This sets isInteractive = false, which causes isInProcessEnabled() to return true unconditionally — overriding the user's explicit teammateMode: "tmux" setting.

The TmuxBackend still initializes (runs tmux -V successfully), but at spawn time the isInProcessEnabled() gate short-circuits to in-process mode. The tmux-shim log confirms zero split-window/send-keys calls — only startup -V checks.

Evidence

1. teammateMode: "tmux" is set in settings.json
2. tmux -V succeeds (returns psmux 0.3.3 via a shim)
3. A psmux session is running and all required tmux subcommands work
4. Named teammates spawn successfully — but always in-process
5. tmux-shim log shows no split-pane commands, only -V at startup
6. Tested from cmd.exe (real Windows console) and winpty (PTY wrapper) — same result

Expected Behavior

When a user explicitly sets "teammateMode": "tmux", this should force the tmux/split-pane code path regardless of isTTY status. The isTTY check makes sense for "teammateMode": "auto" (as a heuristic), but should not gate an explicit user override.

Suggested Fix

In the isInProcessEnabled() logic, check teammateMode before the isInteractive gate:

// If user explicitly requested tmux mode, respect it
if (teammateMode === "tmux") return false;

// Otherwise, fall back to auto-detection
if (!isInteractive) return true;
// ... rest of existing logic

This would allow Windows users with a tmux-compatible backend (psmux, WSL tmux, etc.) to use split-pane mode when they explicitly opt in.

Workaround

Currently, the only option on Windows is in-process mode. WSL + real tmux works but requires running Claude Code entirely inside WSL.