# libtmux::Connection::set_pane_output

- **Module:** libtmux::Connection
- **Package:** libtmux-cxx
- **Language:** C++
- **Kind:** method
- **Source:** https://github.com/libtmux/libtmux-cxx/blob/393d4b0ad666f18a6581f1eb281741a75a7503f0/include/libtmux/control.hpp#L304
- **Page:** https://libtmux.org/en/cxx/latest/reference/libtmux-connection-set_pane_output/

```
libtmux::Connection::set_pane_output(pane: std::string_view, deliver: bool, deadline: std::chrono::steady_clock::time_point) -> expected< void, ProtocolError >
```

Stop or resume `output` for one pane, on a connection that asked for it.

The direction is not symmetrical, because tmux is not: a connection that started without `pane_output` cannot be made to listen to anything, and muting is the only per-pane control it offers. So this narrows what a listening connection receives; it cannot widen a silent one.

Resuming clears both mute and pause, starting at tmux's current output offset. What a caller sees for output produced while muted differs by tmux version, and is not this library's choice either way:

Before tmux 3.7, muting stops delivery to this connection only. What the pane printed while muted is lost — resuming never replays it.

On tmux 3.7+, muting stops tmux from reading the pane's pty at all. The pane freezes for every attached client and tool, not only this connection, and what it printed while muted arrives as a backlog on resume (measured against raw tmux, both directions).