libtmux::Server::over_control

Only where that gives the same answer. tmux can end a command's guarded block before the command has finished, so a command goes over the wire only if the typed surface issues it and tmux cannot defer it as sent — split-window without -I or -W, display-message without -I, the listings, and the other commands in the list in server.cpp, each checked against tmux's CMD_RETURN_WAIT. Anything else launches, as it would from this Server: a deferring command, one that acts on the client itself, an alias or an abbreviation this cannot see through. A failure reads as the same CommandFailure a launch would give.

connections spreads commands over that many clients. One is enough for most callers — a connection already carries concurrent requests — and each extra client is attached to session and shows in clients() .

A command with no target resolves against the control client's session rather than the most recently used one. The typed surface always names a target; a caller passing raw commands through run should too.