Bug Report: tmux control mode commands leak into local shell after SSH session disconnect

After a Warpified SSH session disconnects, Warp's background tmux control mode polling loop continues firing new-window commands into the local shell, producing repeated new-window: command not found errors.

Environment

•  Warp feature: Warpify SSH (tmux-based)
•  Local OS: macOS
•  Shell: zsh 5.9

Steps to Reproduce

1. SSH into a remote host and Warpify the session (tmux-based)

2. Let Warp establish its tmux control mode background tasks (git polling, etc.)

3. Exit the SSH session (e.g. run ! exit)

Expected Behavior

Warp tears down the tmux control mode session and stops all background polling when the SSH connection closes.

Actual Behavior

Warp's background loop keeps sending tmux new-window commands to the local shell after disconnect. These appear as:

Master Control : new-window -d -c '/root' -e PATH='...' -PF "background window: ..." '(...git symbolic-ref...)'
new-window: command not found

Additionally, at least one instance of command concatenation was observed.

Warp merged an SSH reconnect attempt with a tmux command into a single malformed string:

Master Control : ssh <host>new-window -d -c '/root' ...
unknown option -- d

This suggests the control mode pipe and main session pipe get crossed during teardown.