r/tmux 9h ago

Showcase Making tmux more accessible with menu options that can manage panes

Enable HLS to view with audio, or disable this notification

4 Upvotes

I have recently started improving tmux usage in my workspace productivity app called Oyren. Briefly, Oyren provides remote codespaces where users can vibecode and run agents 24/7 with no human needed in the loop for some time. My work is to make this length as long as possible without sacrificing quality and cost costraints. I think tmux is a great tool for this problem but it can be not beginner friendly. Especially for someone who is just a vibecoder and is new to development in general. What they need is agents running on their own. They might not be proficient with terminal usage in general. So I added a feature to my app to manage tmux panes and reorganise them as needed.

Would this make tmux easier for you to use?


r/tmux 18h ago

Question tmux over ssm redraw issue with vertical panes

2 Upvotes

I'm seeing a strange tmux display/rendering issue and am looking for ideas. This went away for at first when using iTerm 2, but then it started happening there as well.

Environment:

- Mac (apple terminal)

- AWS EC2 Ubuntu

- Connected via AWS SSM and also tested via SSH-over-SSM

- tmux 3.2a

- Vertical split panes (Ctrl-b %)

Problem:

- If I run `less file.py` (large file) in the RIGHT pane, the LEFT pane gets visually corrupted/redrawn.

- Content from the right pane appears to wrap into or overwrite parts of the left pane.

- Keystrokes are NOT sent to both panes.

- The panes are independent (`%0` and `%1`).

- The issue does NOT occur with a horizontal split (Ctrl-b ").

- The issue does NOT occur outside tmux.

- The issue persists when connecting via normal SSH-over-SSM, so it doesn't seem specific to the interactive SSM terminal.

What I've checked:

- synchronize-panes is off

- tmux panes have correct widths:

- %0 = 120 cols

- %1 = 119 cols

- window width = 240 cols

- `stty size` looks normal

- `wc -L` on the file is only ~122 chars, so not huge lines

- `seq 1 1000` in the right pane does NOT reproduce the issue

- `tmux kill-server` did not help

- Fresh tmux session did not help

- `$TERM` outside tmux: `xterm-256color`

- `$TERM` inside tmux: `screen`

- Added `set -g default-terminal tmux-256color` but behavior unchanged

- Mouse on/off did not resolve it

Additional observation:

- The issue appears to be triggered by full-screen/alternate-screen apps such as `less`, not normal streaming output.

- `Ctrl-L` in the left pane does not fully repaint the display correctly.

Has anyone seen a tmux rendering bug that only affects left/right pane splits, especially with `less` or other full-screen applications?