I have to say, it’s often frustrating talking about #tmux command mode capable terminal programs like #iTerm2 and #WezTerm because it absolutely subverts the expectations of the terminal multiplexor.
tmux is like a window server for ttys, and a client TUI window manager in one executable.
When your terminal program can provide the window manager UI and communicate using the command protocol client mode to the tmux “window server,” several things happen differently:
Your local terminal GUI provides all the interaction for managing the session’s terminal layout like tabs, windows, split views. This is the most visible difference. Also you rarely have to think about tmux TUI’s
command escape for window management.
Other tmux client connections using the tmux TUI seamlessly represent the changes you made in the command mode GUI terminal and the reverse is true, it remains compatible. Split a window using the tmux TUI commands and your terminal’s version also splits. TUI clients with local terminal size limits will limit how large other clients can make tabs or windows.
if you ssh to a another host and run a tmux client TUI there, only the current viewable tty information is transferred over the ssh connection. But, if you ssh and attach to a session in command mode, instead of a TUI, your terminal recieves everything happening in all the multiplexed terms in the session, which means more data streams over the ssh connection but also your local terminal’s scrollback limits are now honored and the host you connected to does not have to maintain state to switch display context for the TUI, saving cpu and memory on that host.