Fixing SSH Sessions That Don't Know the Terminal's Actual Size
TUI applications render broken or clipped over SSH, or your terminal doesn't rewrap correctly after resizing the window. The remote shell has a stale idea of your terminal's dimensions — here's how that actually gets synced.
A remote shell over SSH rendering full-screen applications incorrectly, or not adjusting to a resized terminal window, comes down to the remote side having a stale or incorrect idea of your terminal’s actual row and column dimensions.
Step 1: check what the remote shell currently believes about terminal size
stty size
echo "COLUMNS=$COLUMNS LINES=$LINES"Compare this against your terminal emulator’s actual current window size — a clear mismatch confirms the diagnosis directly.
Step 2: understand how terminal size normally gets communicated
Terminal dimensions are normally communicated to the remote shell automatically, via a SIGWINCH signal sent whenever the local terminal window is resized — the remote shell (and any TUI application it’s running) is supposed to receive this signal and query the new dimensions in response.
Step 3: force a manual resize signal if automatic sync isn’t happening
kill -WINCH $$Manually sending SIGWINCH to the current shell process forces it to re-query terminal dimensions immediately — a useful direct fix when the automatic resize notification didn’t reach the shell for some reason.
Step 4: check for a stuck tmux or screen session specifically
tmux attach
# if reattaching to a running session on a different-sized
# terminal, resize is usually automatic — but check the
# tmux status bar's reported size against your actual windowTerminal multiplexers add another layer that tracks its own idea of terminal size independently — detaching from a multiplexer session on one differently-sized terminal and reattaching from another can occasionally leave a stale size cached until the multiplexer itself is prompted to recheck.
Step 5: check your SSH client’s pty allocation settings
ssh -tt user@hostForcing pseudo-terminal allocation explicitly (-tt) ensures the remote side actually has a proper pty to report size through — some specific SSH invocations (particularly ones running a single remote command rather than an interactive session) may not allocate a pty by default at all.
Step 6: check whether the specific TUI application itself handles resize correctly
# most well-behaved ncurses/TUI applications refresh their
# layout automatically on SIGWINCH — a few older or poorly
# maintained ones don'tIf the shell itself correctly reports the right size (confirmed via stty size) but one specific application still renders incorrectly after a resize, the bug may be in that specific application’s own resize handling rather than anywhere in the shell or SSH layer.
Step 7: verify the fix by resizing your terminal window and checking again
stty sizeResizing your local terminal window, then immediately re-checking stty size on the remote side, confirms whether size synchronization is now working correctly going forward, not just whether the current mismatch happened to get corrected once.
Step 8: for a persistent, recurring problem, check your terminal emulator’s own SIGWINCH behavior
A terminal emulator that doesn’t properly send SIGWINCH to the process it’s connected to on every resize (unusual, but possible with some unusual or misconfigured terminal setups) would cause this problem to recur consistently across every SSH session — worth testing with a different terminal emulator if the problem persists across otherwise-unrelated remote hosts.
Why this is fundamentally a signal-delivery problem, not an SSH-specific bug
Terminal size synchronization depends on SIGWINCH actually being generated and delivered correctly through however many layers sit between your physical terminal window and the remote shell process — SSH, tmux, and any TUI application in between all need to participate correctly in this chain, which is why the fix sometimes lives at a different layer than where the symptom first appears.