starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-24 16:05:21 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Windows Terminal randomly sends bracketed end marker to tmux when pasting #23589

New Issue
Closed
opened 2026-01-31 08:46:38 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 08:46:38 +00:00
Owner
Copy Link

Originally created by @mihaifm on GitHub (Sep 3, 2025).

Windows Terminal version

1.24.2372.0

Windows build number

10.0.26100.4946

Other Software

tmux 3.5a

Steps to reproduce

Stock Debian Trixie via ssh.

apt install tmux
tmux
cat -v

Now paste some text with ctrl-shift-v or ctrl-v. After some tries the ^[[201~ sequence can be seen. It's totally random, sometimes it might take multiple pastes to see it.

Note that only the end marker is seen, never the begin marker ^[[200~

While some shells (bash, zsh) disregard the sequence without causing any issues, this is very problematic for ksh for example. In any case, regardless of what the shell does, the fact that the end marker is randomly being sent seems like a bug.

Issue replicates on other Linux distros like Redhat, with latest version of tmux and Windows Terminal canary release.

Expected Behavior

No ^[[201~ sequence present in the output of cat -v after pasting text.

Actual Behavior

The ^[[201~ sequence is randomly seen in the output of cat -v after pasting text

Originally created by @mihaifm on GitHub (Sep 3, 2025). ### Windows Terminal version 1.24.2372.0 ### Windows build number 10.0.26100.4946 ### Other Software tmux 3.5a ### Steps to reproduce Stock Debian Trixie via ssh. apt install tmux tmux cat -v Now paste some text with ctrl-shift-v or ctrl-v. After some tries the `^[[201~` sequence can be seen. It's totally random, sometimes it might take multiple pastes to see it. Note that only the end marker is seen, never the begin marker `^[[200~` While some shells (bash, zsh) disregard the sequence without causing any issues, this is very problematic for ksh for example. In any case, regardless of what the shell does, the fact that the end marker is randomly being sent seems like a bug. Issue replicates on other Linux distros like Redhat, with latest version of tmux and Windows Terminal canary release. ### Expected Behavior No `^[[201~` sequence present in the output of `cat -v` after pasting text. ### Actual Behavior The `^[[201~` sequence is randomly seen in the output of `cat -v` after pasting text
claunia added the Needs-TriageIssue-BugNeeds-Attention labels 2026-01-31 08:46:38 +00:00
claunia commented 2026-01-31 08:46:39 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 3, 2025):

Terminal will only send bracketed paste sequences if the application on the other end has requested it.

I suspect this is another manifestation of the tmux escape-time change. tmux is likely to be either requesting bracketed paste or proxying a request for bracketed paste through from the application.

If you were to raise your escape time to something more suitable for SSH, does the problem go away/?

Related: 817b621d20, 2e9d7ebf15

500 is far too long for modern terminals and networks

(I find this to be a preposterous justification for lowering it to 10. That isn't even long enough for a packet to make it across the entire US (as a point of reference).)

@DHowett commented on GitHub (Sep 3, 2025): Terminal will only send bracketed paste sequences if the application on the other end has requested it. I suspect this is another manifestation of the tmux `escape-time` change. `tmux` is likely to be either requesting bracketed paste _or_ proxying a request for bracketed paste through from the application. If you were to raise your escape time to something more suitable for SSH, does the problem go away/? Related: https://github.com/tmux/tmux/commit/817b621d2078137b4ddea78835f609a9d7bac339, https://github.com/tmux/tmux/commit/2e9d7ebf15615b51b014a12de03b0e5483aadf99 > 500 is far too long for modern terminals and networks (I find this to be a preposterous justification for lowering it to 10. That isn't even long enough for a packet to make it across the entire US (as a point of reference).)
claunia commented 2026-01-31 08:46:39 +00:00
Author
Owner
Copy Link

@mihaifm commented on GitHub (Sep 3, 2025):

Got it. Raising escape-time to 100 from the default 10 fixed it.

@mihaifm commented on GitHub (Sep 3, 2025): Got it. Raising `escape-time` to 100 from the default 10 fixed it.
claunia commented 2026-01-31 08:46:39 +00:00
Author
Owner
Copy Link

@mihaifm commented on GitHub (Sep 4, 2025):

On the other hand, I can see why you might want to set escape-time to a low value: it's also the timeout for the <Esc> key. You don't want to wait 500 ms after pressing Esc to exit Insert mode in Vim. Esc is also the same as Alt in Linux, so pressing <Esc>+j triggers the keymap for <Alt>+j in Vim. Setting escape-time to 10 would prevent that.

Not sure what the solution is here. You can't just ask the user to find a middle ground for the setting. What if I paste 10MB of text. That obviously might exceed the number of milliseconds I set for escape-time. tmux probably needs a different setting just for paste, say paste-time = 500 while keeping escape-time = 10.

@mihaifm commented on GitHub (Sep 4, 2025): On the other hand, I can see why you might want to set `escape-time` to a low value: it's also the timeout for the `<Esc>` key. You don't want to wait 500 ms after pressing Esc to exit Insert mode in Vim. Esc is also the same as Alt in Linux, so pressing `<Esc>+j` triggers the keymap for `<Alt>+j` in Vim. Setting `escape-time` to 10 would prevent that. Not sure what the solution is here. You can't just ask the user to find a middle ground for the setting. What if I paste 10MB of text. That obviously might exceed the number of milliseconds I set for `escape-time`. tmux probably needs a different setting just for paste, say `paste-time = 500` while keeping `escape-time = 10`.
claunia commented 2026-01-31 08:46:39 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 4, 2025):

So, I think escape-time only applies to the final sequence rather than the entire paste buffer. The CSI introducer for the end-of-paste sequence is probably itself being split into two different reads.

I also agree that tmux setting a higher escape-time between receiving a start-of-paste and an end-of-paste sequence would work fine for that as well.

@DHowett commented on GitHub (Sep 4, 2025): So, I think `escape-time` only applies to the final sequence rather than the entire paste buffer. The CSI introducer for the end-of-paste sequence is probably itself being split into two different reads. I also agree that tmux setting a higher `escape-time` between receiving a start-of-paste and an end-of-paste sequence would work fine for that as well.
claunia commented 2026-01-31 08:46:39 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 4, 2025):

vim has its own escape timeout (!) though which may confound your example

@DHowett commented on GitHub (Sep 4, 2025): `vim` has its own escape timeout (!) though which may confound your example
claunia commented 2026-01-31 08:46:40 +00:00
Author
Owner
Copy Link

@mihaifm commented on GitHub (Sep 4, 2025):

Ah, I see your point and tested it out. Indeed, the amount of pasted text doesn't influence the issue. Thanks for helping out.

@mihaifm commented on GitHub (Sep 4, 2025): Ah, I see your point and tested it out. Indeed, the amount of pasted text doesn't influence the issue. Thanks for helping out.
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-Bug Needs-Attention Needs-Triage
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#23589
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?