Text selection shifts the viewport on Linux; footer reads obsolete copy_on_select

Start by tracing the selection handler, footer selection hints, and native configuration normalizer described in the report, then reproduce the interaction with the stated Linux, tmux, and terminal conditions. Done means the effective copyOnSelect preference is shared and selection, copy feedback, and footer changes no longer shift the viewport or alter the selected word.

Describe the bug

In an idle Linux conversation viewed through Ghostty on macOS over SSH and tmux, ordinary mouse selection can move the transcript and composer by one terminal row. Double-clicking a word can consequently extend the selection into an adjacent row.

At fixed window geometry, the normal footer hints occupy two rows, but selecting text replaces them with a one-row ctrl+c / right-click copy hint. The composer and bottom-anchored transcript move with that height change. Clearing/restarting the selection restores the taller footer. A local recording captured this transition repeatedly without resizing the window.

There is also a concrete configuration-field mismatch that prevents matching the macOS selection-hint behavior through the supported preference.

Affected version

• Observed Linux behavior: 1.0.85, tmux 3.7, accessed from Ghostty on macOS.
• Read-only inspection found the field mismatch below in shipped bundles for 1.0.83, 1.0.85, 1.0.86, and 1.0.87-0.
• Configuration normalization was checked against the unmodified 1.0.86 native normalizer.

The additional versions are static-inspection results, not claims of Linux runtime reproduction on every version.

Steps to reproduce the behavior

1. Open an interactive Linux conversation with mouse support enabled and enough transcript content to scroll.
2. Leave the conversation idle and scroll to the bottom.
3. Use a window width where the normal footer hints wrap more than the selected-text copy hint. In the observed case, the normal footer included a downloaded-update notice.
4. Without holding Shift, double-click a word in the transcript. Clear the selection and repeat.
5. Observe the footer height change, the one-row transcript/composer movement, and the selection sometimes extending beyond the intended word.

When scrolled away from the bottom, double-clicking can still move the composer even when the transcript appears stationary.

Expected behavior

• Selecting text should not change the viewport geometry underneath the ongoing mouse gesture.
• Double-clicking a word should select that word, not text in a neighboring row.
• The selection handler and its footer hints should honor the same effective copyOnSelect preference.

Additional context

Configuration-field mismatch

The shipped UI passes two different properties from the same settings object:

Consumer	Property read
Actual selection behavior	copyOnSelect
Footer selection hint	copy_on_select

The native normalizer maps the legacy spelling to the canonical spelling; it does not retain both:

Input	Normalized output
{"copyOnSelect":true}	{"copyOnSelect":true}
{"copy_on_select":true}	{"copyOnSelect":true}
{"copyOnSelect":true,"copy_on_select":true}	{"copyOnSelect":true}

Consequently, the footer reads an absent property and falls back to its platform default: true on macOS, false on Linux. Setting copyOnSelect=true on Linux therefore does not suppress the manual-copy hint as intended. Adding the legacy key cannot bridge the mismatch because normalization removes it.

This is a shared-code defect with platform-dependent behavior, not evidence of a Linux-specific terminal or mouse-protocol failure.

Layout and selection interaction

The selection handler computes the release endpoint against the current viewport/scroll geometry. If the footer changes that geometry between press and release, the same physical pointer position can map to a different content row.

The transient copied to clipboard feedback is another footer-content transition. A separate isolated Mac UI probe also observed one-row movement with a wrapped footer during copy feedback. Fixing the stale field is important, but should not substitute for checking layout and coordinate stability throughout the gesture and feedback cycle.

Workaround and scope

Holding Shift while selecting in Ghostty, then using Cmd+C, avoids the application-owned selection path and was confirmed to avoid the jump. This is a workaround, not the expected ordinary-selection behavior.

Related open report: github/copilot-cli #3496 describes copying a different timeline range than the one selected. I have not established that it has the same root cause.

No private transcript, screenshots, recordings, or diagnostic logs are attached.