# libtmux::Server::over_control

- **Module:** libtmux::Server
- **Package:** libtmux-cxx
- **Language:** C++
- **Kind:** method
- **Source:** https://github.com/libtmux/libtmux-cxx/blob/393d4b0ad666f18a6581f1eb281741a75a7503f0/include/libtmux/server.hpp#L244
- **Page:** https://libtmux.org/en/cxx/latest/reference/libtmux-server-over_control/

```
libtmux::Server::over_control(session: std::string_view, connections: std::size_t = 1) -> expected< Server, ProtocolError >
```

A Server whose commands travel over held-open control clients attached to `session`, rather than one launched process each.

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.