[BUG] Teammate subprocess exits code 1 silently before debug init (tmux send-keys backend)

[BUG] Teammate subprocess exits with code 1 silently before debug system initializes (tmux send-keys backend)

Environment

• Claude Code v2.1.100
• macOS Darwin 24.6.0 (Apple Silicon)
• tmux 3.6a
• zsh with ~1.5s startup time
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 enabled

Description

When spawning a teammate via the Agent tool with team_name, the tmux backend creates a pane and sends the launch command via send-keys. The claude binary starts but exits immediately with code 1 — no stdout, no stderr, no debug log created (even with --debug-file). The failure happens before the debug/logging subsystem initializes.

This is 100% reproducible — every auto-launch via send-keys fails. Manual execution of the identical command in the same pane always succeeds.

Related issues

• #40168 — shell-not-ready race condition (related but distinct; our shell IS ready)
• #42391 — 255-byte command truncation (different root cause)
• #46008 — API key env inheritance (possibly related if auth fails pre-debug-init)
• #38048 — teammateMode config ignored (we also reproduce this)

Reproduction steps

1. Start claude inside a tmux session (tmux new-session -s claude && claude)
2. Enable teams: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 in settings
3. Create a team via TeamCreate
4. Spawn a teammate via Agent tool with team_name and name parameters
5. Observe: new tmux pane appears, command runs twice, exits to bare shell both times

Evidence collected

What works vs. what doesn't:

| Launch method | Works? | Detail |
|---|---|---|
| tmux split-window "env ... claude --agent-id ..." | Yes | Binary runs as pane's initial process |
| tmux send-keys (manual, shell warm) | Yes | Typed into interactive shell after prompt |
| Auto-launch via Agent tool (send-keys) | No | Exit code 1, no output, every time |

Pane buffer from failed auto-launch:

cd /Users/.../workbench && env CLAUDECODE=1 ... claude --agent-id probe@test ...

workbench on main [?]
% cd /Users/.../workbench && env CLAUDECODE=1 ... claude --agent-id probe@test ...

workbench on main [?]
%

Command sent twice (retry), both exit silently. No TUI banner rendered.

Intercepted via zsh preexec hook:

• EXIT CODE: 1
• stdout: empty
• stderr: empty
• --debug-file /tmp/debug.log added to command — file never created
• Binary exits before debug system initializes (~first 50ms of startup)

Successful manual run debug log shows:

[DEBUG] MDM settings load completed in 0ms
[DEBUG] [STARTUP] Running setup()...
[ERROR] NON-FATAL: Lock acquisition failed for .../2.1.100 (expected in multi-process scenarios)
[DEBUG] [STARTUP] setup() completed in 33ms
[DEBUG] [Reconnection] Computed initial team context for teammate...
[DEBUG] [TeammateMailbox] readMailbox...

All of this happens in the manual (working) run but NONE of it happens in the auto-launch — the binary exits before any of it.

Additional bug: teammateMode config ignored

Setting "teammateMode": "in-process" in ~/.claude.json has no effect. The backend always resolves to tmux regardless of:

• Being outside tmux ($TMUX not set)
• Explicit config in ~/.claude.json
• Team config showing backendType: "tmux" even when no tmux is available

The earlier debug log confirms: [BackendRegistry] isInProcessEnabled: false (mode=auto, insideTmux=true) — the snapshot reads auto even after config was set to in-process.

Expected behavior

1. Teammate binary should start and connect to the team mailbox
2. If startup fails, error should be surfaced (stderr, exit message, or debug log)
3. teammateMode: "in-process" should be respected

Suggested fix

The tmux backend should use tmux split-window -t ... "cd /path && env ... claude ..." (command as pane argument) instead of split-window + send-keys. We proved this works on every attempt.