Aggressive-resize vs. Window-size persistence for multi-client sessions

Direct answer

aggressive-resize is not expected to introduce significant per-switch overhead, even with several attached clients. It is a size-constraint rule, not a full layout recalculation; tmux only notifies affected clients of the new size when the current window changes. This is an architectural expectation, not a measured benchmark result.

It fails to prevent clipping when a small client attaches while viewing another window, leaves the dashboard in the background, another client enlarges that dashboard window, and the small client switches to it before tmux learns the smaller terminal size. Until a resize or redraw occurs, that client can see clipped output. If every client keeps the dashboard window current, aggressive-resize and the default smallest-client rule protect the same viewer and behave identically.

Confirmed facts

• Default tmux constrains every window in a session to the smallest client attached to that session.
• aggressive-resize constrains a window to the smallest client for which that window is the current window.
• Window switches trigger size notifications only to affected clients, so overhead does not scale with window switches.
• Existing windows may keep the prior setting until changed individually or the session is restarted.

Likely explanation

Layout shifts on large displays happen because a window grows when small clients detach or view other windows, not because of rendering cost. The large client's viewport changes as the session-wide constraint changes.

Steps for this case

1. Read the current value: tmux show-window-option -g aggressive-resize
2. Enable it for new windows: tmux set-window-option -g aggressive-resize on
3. Apply to existing windows individually or restart the session so the setting takes effect everywhere.
4. Confirm your release with tmux -V; aggressive-resize is long-standing, but verify support before rolling it out.

Missing diagnostic

Do smaller clients ever attach while viewing another window, leaving the dashboard in the background? This changes the recommendation: if yes, aggressive-resize will not protect them until they switch to the dashboard and tmux redraws. In that case, default smallest-client sizing or separate sessions per client tier may be more appropriate.

Verification scenario

Attach a small and a large client to one session. Background the dashboard on the small client, enlarge the window from the large client, switch the small client to the dashboard, and observe whether output is clipped.