Mouse text selection becomes erratic in all panes when Claude Code CLI is running in one pane

[favoretti]

Issue Description

When running Claude Code CLI in one pane of a split-window Ghostty session, mouse text selection becomes erratic and unreliable in all other panes, not just the pane running Claude Code. This suggests Claude Code is affecting Ghostty's global mouse/selection state rather than being isolated to its own pane.

The issue isn't limited to the pane where Claude Code is running - text selection breaks in completely separate panes that are just running regular shells or other programs. This cross-pane contamination suggests Claude Code may be sending terminal escape sequences or triggering behavior that affects Ghostty's global mouse event handling.

Potentially related issues:

• Mouse input becomes stuck and selection scroll runs forever after switching focus #10713 - "Mouse input becomes stuck and selection scroll runs forever" (mentions AI CLI agents)
• tmux mouse mode doesnt reliably select panes #5362 - tmux mouse mode selection issues (right-click state getting stuck)
• Mouse Click/Drag not registering on latest build of ghostty inside tmux #9018 - Mouse click/drag issues inside tmux

This makes split-pane workflows with Claude Code nearly unusable, as you can't reliably select/copy text from other panes while Claude Code is running.

Expected Behavior

Mouse text selection should work normally in all panes, regardless of what's running in other panes. Each pane should have isolated mouse/selection state.

Actual Behavior

Text selection becomes erratic even in panes that are NOT running Claude Code. The selection behavior is unreliable and doesn't work as expected.

Reproduction Steps

1. Open Ghostty
2. Create a split pane layout (e.g., Cmd+D to split right)
3. In one pane, start Claude Code CLI: claude
4. In the other pane(s), run a normal shell or any other program
5. Try to select text with the mouse in either the non-Claude Code panes or Claude Code pane
6. Observe that text selection is erratic and unreliable

Ghostty Logs

No response

Ghostty Version

Version: cdcfac4e4
Build: 14456
Commit: cdcfac4e4
Channel: tip

OS Version Information

macOS (latest)

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

# No special configuration required to reproduce
# Issue occurs with default Ghostty settings

Additional Relevant Configuration

Claude Code version: 2.0.50
Shell: zsh

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[knl]

I'm seeing this on macOS as well.

[mitchellh]

Can you please describe "erratic and unreliable" in more specific terms? Can you provide a video of this behavior?

[favoretti]

Basically the cursor turns to arrow and starts selecting from a random point. When I click on a starting point I want - it chooses a random one.

I'll make a video later tonight, need to run claude in it for a while to trigger. I'm assuming Claude CLI sends some escape sequences that aren't taken well by Ghostty, but I'm not really sure how to catch them.

[favoretti]

clicking2.mov

Here's an example. Sorry, can't make it bigger than 480p, file becomes too large.

[tedsteen]

Same thing here on macOS.

I'm not using Claude CLI, but I see the same behaviour.
I click and drag to select some text and copy. When I go paste somewhere else it's not actually copied and when I go back to Ghostty it acts as if the release of the mouse (from when I previously selected the text to copy) never happened. So I move the mouse around and there's an ongoing selection from the point the first mouse down happened to wherever my mouse is on the screen.

I have also noticed that it becomes hard or sometimes impossible to resize the panes and I think it's related. Something with the mouse down state that's stuck.

[mitchellh]

This is fixed, will be in 1.3.1

[favoretti]

@mitchellh worked fine for a few days, came back with the latest build from last night.. regression or some new cause?

[msjurset]

Hitting this regression on /Ghostty 1.3.1 / Build 15212 / commit 332b2ae (macOS), with Claude Code CLI running in one or more splits.

Symptoms:

1. First text selection after activation works correctly — anchor at click, extends to release.
2. Every subsequent click behaves as if it's the end of a drag from the previous click point, not a new anchor. A plain single click (no drag) is enough to arm this — the next click then highlights from the prior click point to the new one.
3. Once (2) starts, focus-follows-mouse between splits also stops working — I have to click (sometimes multiple times) to move focus.
4. ⌘+hover no longer activates URLs either — link detection/hover feedback is dead until reset.
5. Switching macOS Spaces away and back resets everything to working state — until the next click, when it recurs.

Not fullscreen-specific (reproduces in windowed mode).

Because the trigger is a plain mouseDown (no drag, no release-over-text), this looks less like a stuck "button-held" state and more like the mouseDown handler is failing to reset the selection anchor on subsequent clicks, while mouseDragged/mouseUp continue to fire normally against the stale anchor. The fact that selection anchoring, focus-follows-mouse, and ⌘+hover URL activation all break together — and all recover together on a Space switch — suggests the whole mouse/hover event pipeline for the window is getting gated off after the first click, not just the selection state machine. A full app reactivation cycle clears it; losing/regaining key-window focus within the same Space does not.

Happy to capture ghostty +show-config, traces, or test a patch build if helpful.

[mark-jaeger]

Still reproducible on 1.3.1 stable (macOS)

Ghostty 1.3.1, channel: stable
macOS (Darwin 25.5.0), Metal renderer

Setup: one window with multiple splits, each attached to remote sessions (zmx over SSH). focus-follows-mouse = true is set.

Symptoms match this thread exactly:

• After working normally for a while, a click in the window stops selecting from the pointer position — instead every click/drag continues a selection anchored at the previous click point (confirmed: the phantom anchor is exactly where I last clicked).
• cmd+click / cmd+hover link activation stops working in the same window at the same time.
• Shift+drag behaves identically to plain drag, so this is not app mouse-reporting capture.
• Other windows remain unaffected; a fresh window works fine.

This has been persistent for months across 1.2 → 1.3.1. Happy to provide more debug info if useful.