# control.ControlSender.mute_pane

- **Module:** control.ControlSender
- **Package:** libtmux
- **Language:** Rust
- **Kind:** method
- **Source:** https://github.com/libtmux/libtmux-rs/blob/f0e37052c232636b61d095817046e6bfc8f2ca40/crates/libtmux/src/control.rs#L865
- **Page:** https://libtmux.org/en/rs/latest/reference/control-controlsender-mute_pane/

```
control.ControlSender.mute_pane(self, pane: &PaneId) -> Result<(), Error>
```

Stop tmux sending this connection what a pane writes.

A control client is sent the output of every pane in the session it
attached to, which is one window's worth or a hundred. One pane running
`yes` moves more than 20 MB in two seconds, and a client tmux judges
five minutes behind is disconnected with `too far behind`, so
discarding the unwanted panes on arrival is not enough.

Muting a pane that does not exist is not an error; tmux ignores an
unresolvable id here.

Below [`crate::since::CONTROL_PANE_OFF`] this pauses the pane rather
than taking it out of the stream, because taking it out crashes the
server. tmux keeps reading the pane's pty either way, discarding what
this connection does not want; a paused pane costs only that
connection's own back-pressure, and [`ControlEvents`] sees
[`Event::Paused`] for it.

At or above that release, taking the pane out of the stream also stops
tmux reading its pty at all -- for every attached client, not only this
connection, and for a one-shot reader such as `capture-pane` too --
until [`Self::unmute_pane`] or [`Self::resume_pane`] turns it back on.
A human attached to the same pane sees it stop updating, and the pane's
own program can block on `write` once the kernel's pty buffer fills.
What arrives once resumed is therefore a backlog, not a gap: see
[`Self::unmute_pane`].

# Errors

Returns an error when the connection has closed or tmux refuses the
stream change.