starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Mosh + WSL - cannot copy-and-paste #16944

New Issue
Closed
opened 2026-01-31 05:28:00 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 05:28:00 +00:00
Owner
Copy Link

Originally created by @kellytrinh on GitHub (Mar 8, 2022).

Windows Terminal version

1.11.3471.0

Windows build number

Version 10.0.19043.1526

Other Software

Ubuntu 18.04 running under WSL
mosh 1.3.2
tmux 2.6

Steps to reproduce

  1. within setting.json have tab setup as "wsl.exe mosh hostname"
  2. host has tmux with mouse support via tmux.conf "set -g mouse on"
  3. open session with the host using that tab
  4. try to copy text by selecting text

Expected Behavior

Expected that the text is copied and can paste as usual from windows clipboard

Actual Behavior

The clipboaard is untouched. Previous contents still there.

Note: Isolated to some interaction between mosh when run from 'settings.json' in windows terminal.

For the same setup:

  • If "settings.json" has "wsl.exe ssh hostname", then copy-and-paste works fine.
  • If tab opened via ssh and within that ssh session do "mosh hostname", the copy-and-paste also works fine.
Originally created by @kellytrinh on GitHub (Mar 8, 2022). ### Windows Terminal version 1.11.3471.0 ### Windows build number Version 10.0.19043.1526 ### Other Software Ubuntu 18.04 running under WSL mosh 1.3.2 tmux 2.6 ### Steps to reproduce 1. within setting.json have tab setup as "wsl.exe mosh _hostname_" 2. host has tmux with mouse support via tmux.conf "set -g mouse on" 3. open session with the host using that tab 4. try to copy text by selecting text ### Expected Behavior Expected that the text is copied and can paste as usual from windows clipboard ### Actual Behavior The clipboaard is untouched. Previous contents still there. Note: Isolated to some interaction between mosh when run from 'settings.json' in windows terminal. For the same setup: * If "settings.json" has "wsl.exe ssh _hostname_", then copy-and-paste works fine. * If tab opened via ssh and within that ssh session do "mosh _hostname_", the copy-and-paste also works fine.
claunia commented 2026-01-31 05:28:02 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 8, 2022):

When you enable set -g mouse on in tmux, you're entering "mouse mode". That gives tmux full control over the mouse events, including clicking and dragging. So any selection you might see on the screen isn't actually a selection created by the Terminal, but rather one owned by tmux itself. If you want to escape the tmux mouse handling, you can hold shift while dragging, which will make a normal Terminal selection. That, you should be able to still copy as expected.

Does that work as expected for you?

@zadjii-msft commented on GitHub (Mar 8, 2022): When you enable `set -g mouse on` in tmux, you're entering "mouse mode". That gives tmux full control over the mouse events, including clicking and dragging. So any selection you might see on the screen isn't actually a selection created by the Terminal, but rather one owned by tmux itself. If you want to escape the tmux mouse handling, you can hold <kbd>shift</kbd> while dragging, which will make a normal Terminal selection. That, you should be able to still copy as expected. Does that work as expected for you?
claunia commented 2026-01-31 05:28:02 +00:00
Author
Owner
Copy Link

@kellytrinh commented on GitHub (Mar 8, 2022):

The hold-shift workaround doesn't respect vertical panes in tmux (the selection doesn't wrap around the pane borders) so is not helpful unfortunately.

I do see that tmux is capturing the mouse events. When using ssh, when I am selecting text, tmux will highlight the selection, wrapping around the vertical pane borders correctly, and upon release of mouse button the selection is copied correctly. But when switch over to mosh then it doesn't work anymore - during the hold-mouse-button phase tmux is highlighting the selection as before; but upon releasing mouse button - the selection isn't copied to clipboard.

Perhaps issue is something around how Windows Terminal is passing the mouse-button-release event to ssh vs mosh?

@kellytrinh commented on GitHub (Mar 8, 2022): The hold-shift workaround doesn't respect vertical panes in tmux (the selection doesn't wrap around the pane borders) so is not helpful unfortunately. I do see that tmux is capturing the mouse events. When using ssh, when I am selecting text, tmux will highlight the selection, wrapping around the vertical pane borders correctly, and upon release of mouse button the selection is copied correctly. But when switch over to mosh then it doesn't work anymore - during the hold-mouse-button phase tmux is highlighting the selection as before; but upon releasing mouse button - the selection isn't copied to clipboard. Perhaps issue is something around how Windows Terminal is passing the mouse-button-release event to ssh vs mosh?
claunia commented 2026-01-31 05:28:02 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 6, 2022):

Hey sorry, haven't had the chance to dig in too much further. The triage queue is deep, sorry this got lost. My theory is that this has to do with OSC52, "MANIPULATE SELECTION DATA", or "copy to clipboard". (see implementation in #5823).

I wonder if mosh is eating the OSC52's. That would prevent the Terminal from ever being told what the new clipboard contents should be.

@zadjii-msft commented on GitHub (Jul 6, 2022): Hey sorry, haven't had the chance to dig in too much further. The triage queue is deep, sorry this got lost. My theory is that this has to do with OSC52, "MANIPULATE SELECTION DATA", or "copy to clipboard". (see implementation in #5823). I wonder if mosh is eating the OSC52's. That would prevent the Terminal from ever being told what the new clipboard contents should be.
claunia commented 2026-01-31 05:28:03 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 6, 2022):

https://andrewmzhang.com/blog/2020/osc-52-patch-for-vte-0425/
https://gist.github.com/yudai/95b20e3da66df1b066531997f982b57b
https://github.com/mobile-shell/mosh/pull/1054

Yea this might be a mosh issue. Can you try changing your tmux conf like in the above posts, to see if that remedies this/?

@zadjii-msft commented on GitHub (Jul 6, 2022): https://andrewmzhang.com/blog/2020/osc-52-patch-for-vte-0425/ https://gist.github.com/yudai/95b20e3da66df1b066531997f982b57b https://github.com/mobile-shell/mosh/pull/1054 Yea this might be a mosh issue. Can you try changing your tmux conf like in the above posts, to see if that remedies this/?
claunia commented 2026-01-31 05:28:03 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 10, 2022):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Jul 10, 2022): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Question Needs-Author-Feedback Needs-Tag-Fix Needs-Triage No-Recent-Activity Resolution-Answered Tracking-External
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#16944
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?