- rmux 0.7.0 (installed via Homebrew, macOS arm64)
- Terminal: Ghostty (latest stable)
- Outer `$TERM` = `xterm-ghostty`
- Inner `$TERM` (inside rmux) = `tmux-256color`
- `~/.rmux.conf`:
set -g aggressive-resize on
set -g mouse on
- `rmux show -g mouse` → `mouse on`
## Symptom
Mouse wheel scrolling does nothing inside an rmux session in Ghostty.
- Scroll wheel in a pane: no effect, neither enters copy-mode nor scrolls scrollback
- Drag-select with plain mouse: nothing selected (events appear consumed by rmux but
no copy-mode selection appears)
- `Shift+drag` works — bypasses rmux and uses Ghostty's native selection, confirming
the terminal itself receives mouse events fine
- Keyboard copy-mode works: `C-b [` then arrows / PgUp / PgDn / `j`/`k` all
scroll correctly
- Once inside copy-mode, scroll wheel **does** work (so wheel event reception isn't
entirely dead — it's specifically wheel-to-enter-copy-mode and drag-selection that
are broken)
## Expected
In tmux with `set -g mouse on`, rolling the wheel in a normal pane automatically
enters copy-mode and scrolls scrollback. Drag-select highlights text and copies to the
tmux buffer.
## Notes
PR #16 (cherry-picked 2026-06-04) addressed wheel-order issues for terminals requiring
`?1000h` before `?1002h`. Symptom persists in 0.7.0 with Ghostty, suggesting either
the fix didn't ship in 0.7.0 or Ghostty's DEC mode negotiation needs a different
sequence.
Happy to capture an `RMUX_LOG=debug` trace or PTY transcript if helpful.
Environment