tmux mouse mode doesnt reliably select panes

[yonilerner]

When tmux mouse mode is enabled, selecting panes with the mouse is not reliable. Sometimes clicking seems to do nothing, or lags into a selection mode. Ill attach av video to demonstrate. I have noticed that sometimes clicking fairly quickly in quick succession (slower than a double click) will be more reliable

Screen.Recording.2025-01-24.at.4.44.35.PM.mov

Here's my config:

cursor-style=block
cursor-style-blink=false
shell-integration-features=no-cursor

keybind=global:cmd+opt+t=toggle_quick_terminal
keybind=cmd+right=next_tab
keybind=cmd+left=previous_tab

#theme=Relaxed
#theme=rose-pine-moon
#theme=Solarized Dark - Patched
theme=Solarized Dark Higher Contrast

Edit: I forgot to include important details :)

Macos 14.7.2 (23H311)

Ghostty version 1.0.1
Build 8696
Commit 3f7c3af

[rhodes-b]

could you perhaps use the terminal inspector to view the mouse states? (and post a video here)
Tmux might have some odd behavior on how its reporting mouse events in mouse mode

[yonilerner]

Screen.Recording.2025-01-26.at.3.20.23.PM.mov

I didnt see anything interesting here but Im not sure what to look for

[bgw]

I've noticed similar behavior to @yonilerner. It looks like in the provided screen capture, the "Click State" on the right side of the inspector is "R". Right clicking once in the terminal fixes this. It seems like there's some way for the right mouse button to be stuck in a mouse-down state (maybe when it's used with a modifier key?).

I've encountered this behavior both on macos and Linux (Debian 13, GNOME 48).

[taylrfnt]

I am late to the party, but what $TERM is being used for tmux sessions?

Tmux (depending on your config and overrides as well as versions) doesn't always play nice with xterm-ghostty.

Popular opinion for tmux seems to converge on setting your $TERM value to xterm-256color, you may try that as well.

[bgw]

My experience was with TERM=xterm-ghostty and tmux 3.5a. I was originally using TERM=xterm-256color but ran into other issues (it was a while ago, I don't remember the details).

[00-kat]

The $TERM value outside Tmux should be xterm-ghostty, and the $TERM value inside Tmux should be tmux-256color (preferred, I think) or xterm-256color, if I remember correctly.

[bgw]

Yes, that's the case for me. $TERM outside of tmux is xterm-ghostty. $TERM inside tmux is tmux-256color.

[mitchellh]

Can this still be reproduced on the latest nightly releases? I haven't heard any further reports.

[yonilerner]

Im on 1.1.3 now and havent had issues for a while

[SamCastelain]

I'm on 1.1.3 as well, but I have this issue sometimes. It's also easy to reproduce (@bgw was on the right track):

1. shift + right click to get native macos context menu.
2. Click State is stuck in 'R'.
3. Left click produces a Click State of 'LR'.
4. Right clicking without modifier keys resets the Click State to 'none'.

[adamatom]

I can reproduce this as well on 1.1.3, my config is minimal:

font-family = CaskaydiaCove NF
shell-integration = zsh

Steps to reproduce:
Open ghostty, right click to open the inspector.
Inspector state shows Mouse: Click StatR

• Left clicking in ghostty changes this to StatLR when left click is held, and it changes back to StatR.
• Right clicking does not change the state from StatR, but shows the ghostty click menu.

Start tmux, create a new pane or tab to have something that the mouse can interactive with.
Inspector state shows "Mouse: Click StatR"

• Left clicking show StatLR, and tmux pane/tab is not activated when clicked.
• Right clicking changes the state to Statnone, and the ghostty menu does not appear. After this, left clicking on panes/tabs works in tmux. From here clicking around in tmux is okay.

To break tmux clicking again: with tmux open, shift+right click to get the ghostty menu. Left click outside of the menu to close it. Inspector now stays in StatR and tmux clicking is broken again.

[bgw]

FWIW, I'm still reproducing this on 1.2.0 (tested with macos). I can reliably get into this state by doing shift + right click, and it manifests in the inspector by showing Click State as R until I right click again in tmux, which resets it back to none.

I can get Click State in the inspector stuck as R with or without tmux, it's just that it only causes noticeable issues in tmux.

[yonilerner]

Ya also reproduced on 1.2.0

[wescande]

This issue is wrongly marked as closed/fixed.

But others (and I) can reproduce it. (see thread above)

I can reproduce on ghostty 1.3.0-dev-b4a4830-nix on linux

Some more detailed explanation can be found here #5362 (reply in thread), thanks to @adamatom

TL:DR; To reproduce, with tmux open (I am ssh'ing into tmux, idk if this generate a difference):

• shift + right click to get the ghostty menu.
• Left click outside of the menu to close it
• Observe: you can't change pane in tmux anymore

FYI @mitchellh

[00-kat]

Maybe it should be a new discussion now, even the OP says they can reproduce it again in 1.2 but it might have a different cause.

[ilyagr]

I opened #9312 a while ago, now I found this related discussion. #9312 could serve as that new discussion.

[XhstormR]

1.3.2 The bug can be successfully reproduced.

└──❯ ghostty +version
Ghostty 1.3.2-main-+f146db553

Version
  - version: 1.3.2-main-+f146db553
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

[bgw]

This still appears to be an issue for me in Ghostty 1.3.1 on macOS.

As before, if I shift+right click, the terminal inspector shows the "Click State" as stuck at "R", and it never resets until I right click again without a modifier key held.