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
- Open an interactive Linux conversation with mouse support enabled and enough transcript content to scroll.
- Leave the conversation idle and scroll to the bottom.
- 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.
- Without holding Shift, double-click a word in the transcript. Clear the selection and repeat.
- 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.
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 copyhint. 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
The additional versions are static-inspection results, not claims of Linux runtime reproduction on every version.
Steps to reproduce the behavior
When scrolled away from the bottom, double-clicking can still move the composer even when the transcript appears stationary.
Expected behavior
copyOnSelectpreference.Additional context
Configuration-field mismatch
The shipped UI passes two different properties from the same settings object:
copyOnSelectcopy_on_selectThe native normalizer maps the legacy spelling to the canonical spelling; it does not retain both:
{"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=trueon 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 clipboardfeedback 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.