[BUG] Agent Teams: tmux/auto teammates crash on spawn — non-TTY stdin triggers --print with no prompt (2.1.195)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/29293
2. https://github.com/anthropics/claude-code/issues/58724
3. https://github.com/anthropics/claude-code/issues/60987

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Please keep this open rather than auto-closing as a duplicate. All three cited issues are closed, and none were fixed:

• #29293 and #58724 were closed as duplicates (the chain bottoms out in more bot-closed dupes like #27729).
• #60987 was closed NOT_PLANNED on 2026-06-23 ("inactive for too long") — even though it was labeled bug / has repro / area:agents and independently reached the same root cause this issue identifies: the harness spawns the teammate without a PTY, so Claude sees a non-TTY stdin, auto-enables --print, and dies with no prompt.

That independent corroboration is the point: this is one unfixed bug that keeps getting reported and auto-closed without a fix ever shipping. This issue reproduces on the latest release (2.1.195) and adds a minimal stdin-TTY isolation (identical launch line: ✅ under a PTY, ❌ without). Please leave it open as the live tracking issue for the no-PTY teammate spawn failure. 👎 to auto-closure.

The core issue here is that the spawn path for tmux teammates doesn't allocate a PTY before exec, so Claude Code's own stdin-detection heuristic sees a non-TTY and falls into --print mode without a prompt to consume. It then fails rather than waiting for mailbox input.

The PTY allocation fix is the right long-term answer. In the meantime, a few workarounds beyond in-process mode that some people have had luck with:

• Wrap the teammate spawn in script -q /dev/null claude ... on macOS to force PTY allocation
• Use expect -c 'spawn claude ...; interact' to get a PTY without an interactive terminal
• Pass the initial prompt as a -p argument to the spawn command directly (bypasses the stdin ambiguity entirely)

The regression from 2.1.179 is worth flagging separately: in-process mode losing split-pane visibility is a real cost. The tmux split-pane path was the whole point of teammateMode for monitoring what each agent is actually doing. Losing that visibility makes it harder to catch when a teammate has gone off the rails.

Seconding the request for a fix that keeps split-pane visibility while getting PTY stdin right.

Some code-level detail from the shipped 2.1.195 bundle (GIT_SHA 4603aa3f2ea164bd0974f82eb413ae7acc99a7ee), in case it helps whoever picks this up. This is not environment-specific — the relevant code is in the binary itself, and the same failure has been reported on macOS (#60987, labeled platform:macos) and against the Vertex AI backend (#27729), neither of which involves tmux or a Nix wrapper.

Spawn path. The teammate is launched via the agent runner with:

pathToClaudeCodeExecutable: process.execPath

i.e. it re-invokes its own binary by absolute path. The child is given a non-TTY stdin, so Claude's stdin heuristic falls into --print mode and then aborts because there's no prompt on stdin — instead of allocating a PTY or passing the initial prompt as an argument. (CLAUDE_CODE_EXECPATH is only written into the child env via getEnvironmentOverrides — c[Gmo]=process.execPath — it is not read as an override.)

The fix is already in the box. The bundle ships node-pty (@cdktf/node-pty-prebuilt-multiarch) and a background-agent PTY rendezvous mechanism (CLAUDE_BG_PTY_AUTH, CLAUDE_BG_SOCKET_TOKENS_PATH). The tmux/auto teammate spawn path just doesn't route through it — it spawns with a piped stdin instead. Routing tmux teammates through the same PTY path (or passing the initial prompt as -p to sidestep the stdin ambiguity entirely) should resolve it.

Why the community workarounds don't generalize. script -q … claude … / expect -c 'spawn claude …' all assume you control the spawn command. Because the spawn targets process.execPath directly, packaged installs — the official versioned binary, Homebrew, Nix — have no wrapper seam to inject a PTY: the spawn steps over any claude wrapper script and calls the real binary. So in-process (also the default since 2.1.179) is the only general workaround, and the fix really does need to live in the spawn path.

Repro is in the issue body: the identical launch line succeeds under a PTY (script -qec '<line>' /dev/null) and fails with --print without one — stdin's TTY-ness is the only variable.

Thanks for the detailed isolation work. I tried to reproduce this on Linux with tmux 3.4 on 2.1.233: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, "teammateMode": "tmux", running inside tmux, then asking Claude to spawn a teammate named alice. The teammate pane opened and started a normal interactive session that received its instructions and replied — no crash. I then repeated the exact same steps on 2.1.195 (your version) and it also worked, and even forcing claude </dev/null inside a tmux pane starts interactively on both versions.

One note on the diagnosis: bare claude decides between interactive and --print mode based on whether stdout is a terminal, not stdin (docs) — piped stdin alone is recovered via /dev/tty. So the dead pane suggests something in your environment is making the spawned command's stdout not a TTY inside the pane.

Could you share:

• How Claude Code is installed (nixpkgs package, native installer, or npm), and whether which claude resolves to a wrapper script — if so, its contents
• Your tmux default-shell / default-command settings (tmux show -g default-shell default-command)
• From a shell in the same tmux server, the output of sh -c 'tty; ls -l /proc/$$/fd/0 /proc/$$/fd/1' run via tmux respawn-pane
• Whether it still reproduces on the latest release

🤖 Generated with Claude Code

We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.