By default, running tmux in Windows Terminal doesn’t show the scroll bar, and doesn’t allow you to scroll with the mouse scroll wheel.
As a solution, people often suggest turning on tmux’s mouse mode, e.g. by adding set -g mouse on to ~/.tmux.conf. This re-enables scrolling with the mouse scroll wheel but interferes with selecting text and disables right-click-to-paste, and still doesn’t enable the right scroll bar.
Fortunately, you can enable native xterm scrolling in tmux by adding set -g terminal-overrides 'xterm*:smcup@:rmcup@' to ~/.tmux.conf, as suggested here and (with a slight variation) here. This restores the usual scrolling behavior. According to the second link, it works by “fooling [tmux] into thinking that the terminal has no ‘alternate screen’ mode”, and xterm* should be replaced by the output of echo $TERM if you’re not using xterm.
However, it’s glitchy: when attaching to an existing tmux session (tmux a or tmux attach), scrolling up shows you the contents of the parent terminal session from before you attached, instead of the past contents of the tmux session. One of the comments to the first link complains that this solution “doesn’t keep the scrollback buffer after a(n) (re)attach” – but that’s not actually true, since if you zoom out a bunch (e.g. with Ctrl + mouse wheel) and then zoom in again, you can see the entire past contents of the tmux session, or at least as far back as the number of lines you were able to fit on the screen when you zoomed out. The farther you zoom out, the farther back you’re able to scroll when you zoom in.
Is there a way to skip this zoom in/zoom out trick and get Windows Terminal to re-render the entire tmux scrollback buffer when attaching? Although I don’t have another terminal emulator set up to test it, I suspect this glitch is an xterm issue and isn’t specific to Windows Terminal. Honestly, set -g terminal-overrides 'xterm*:smcup@:rmcup@' seems like a hack anyway, so maybe there’s a more robust way to re-enable native xterm scrolling?
