tmux/Q/Why doesn't prefix Alt-Left or Alt-Right resize the inner horizontal split in a nested tmux layout (outer top-bottom split and lower left-right split), while Alt-Up or Alt-Down still move the outer boundary?
Why doesn't prefix Alt-Left or Alt-Right resize the inner horizontal split in a nested tmux layout (outer top-bottom split and lower left-right split), while Alt-Up or Alt-Down still move the outer boundary?
Answer
- AI/Response
- Short answer: The tmux/Keyshort/Pane/Resize Pane bindings are still calling
resize-pane on the active pane. In a nested layout they only move the immediate vertical border between the two bottom panes. If that border cannot move—most often because the other bottom pane is already at tmux’s minimum width—the command no-ops, which looks like “resize doesn’t work.” Alt-Up / Alt-Down still move the outer (full-width) horizontal divider, where there is usually more slack in rows than you have spare columns in the bottom row, so those resizes are more likely to succeed. How tmux applies resize-pane
resize-pane -L / -R / -U / -D nudges the edge of the current pane in that direction against its sibling along that axis, inside the layout “cell” that already contains the pane (tmux(1) — resize-pane).- The maintainer describes this as resizing up to the limit of the cell that contains the active pane;
resize-pane does not recursively shrink or grow panes outside that cell the way dragging borders with the mouse sometimes can in awkward layouts (tmux issue #1774, issue #4381).
Why the inner left/right split often “won’t budge”
- Minimum pane size: tmux enforces a minimum width and height for panes (on the order of a few cells; see discussion around
PANE_MINIMUM in tmux issue #1480). If bottom-left is already as narrow as allowed, you cannot steal more columns for bottom-right, so both horizontal nudges can appear dead until you first give slack (e.g. widen the left pane with the opposite horizontal resize, or resize from the other pane). - Asymmetric slack: After a top/bottom split, the bottom row may be short in height but still wide; the limiting factor for horizontal resize is columns shared with the sibling, not the whole window. Vertical resize of the outer split uses full window width and many rows, so it succeeds more often even in the same session.
Things to verify
- Run tmux/list-keys (pipe through
rg resize if you like) and confirm prefix + M-Left / M-Right are bound to resize-pane -L / -R as expected for oh-my-tmux. - Check pane widths with
tmux display-message -p '#{pane_width}' after select-pane -L / -R to see whether the sibling is pinned at a tiny width (minimum-size panes block further horizontal steals). - If you need deeper layout changes than one border, use
resize-pane -t <target> on specific panes, select-layout, or mouse dragging (Super User — adjusting split sizes).
Sources
- 2026-06-26 Fri Confirmed root cause on macOS / Ghostty
- The primary blocker is not tmux layout or minimum pane width — it is Ghostty's built-in keybind defaults intercepting Option+Arrow before tmux sees them.
ghostty +list-keybinds shows alt+arrow_left=esc:b and alt+arrow_right=esc:f ship as Ghostty defaults, sending readline word-jump (ESC b / ESC f) regardless of macos-option-as-alt. tmux's M-Left/M-Right bindings expect xterm sequences \033[1;3D/\033[1;3C and never receive the keystrokes.- Confirmed by
cat -v in a plain shell: pressing Option+Right prints ^[f, not ^[[1;3C. Alt-Up/Alt-Down work because Ghostty has no built-in default for those directions — they fall through as \033[1;3A/\033[1;3B, which tmux does expect.- The fix (
keybind = alt+arrow_left=esc:[1;3D in Ghostty config) resolves resize but breaks terminal word navigation. Accepted limitation: <prefix> M-Left / <prefix> M-Right are not usable on macOS with Ghostty.