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

win32-input-mode: clipboard paste weird escape sequences #22042

New Issue
Open
opened 2026-01-31 08:01:48 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 08:01:48 +00:00
Owner
Copy Link

Originally created by @ClusterM on GitHub (Aug 2, 2024).

Windows Terminal version

1.21.1772.0

Windows build number

10.0.22631.3958

Other Software

standard ssh, Linux

Steps to reproduce

  1. Copy "test" string to clipboard
  2. Run Terminal
  3. Connect to Linux via SSH
  4. Type printf "\x1b[?9001h" to enable win32-input-mode
  5. Right-click on the terminal window to paste text from a clipboard

Expected Behavior

;4;20;116;1;0;1_;4;20;116;0;0;1_;18;101;1;0;1_;18;101;0;0;1_;3;31;115;1;0;1_;3;31;115;0;0;1_;4;20;116;1;0;1_;4;20;116;0;0;1_

It's t, e, s, t key presses.

Actual Behavior

;0;27;1;0;1_;0;91;1;0;1_;0;50;1;0;1_;0;48;1;0;1_;0;48;1;0;1_;0;126;1;0;1_4;20;116;1;0;1_4;20;116;0;0;1_;18;101;1;0;1_;18;101;0;0;1_3;31;115;1;0;1_3;31;115;0;0;1_4;20;116;1;0;1_4;20;116;0;0;1_;0;27;1;0;1_;0;91;1;0;1_;0;50;1;0;1_;0;48;1;0;1_;0;49;1;0;1_;0;126;1;0;1_

Decoded:

| Sequence          | Vk | Sc  | Uc  | Kd   | Cs | Rc | Description           |
|-------------------|----|-----|-----|------|----|----|-----------------------|
| `;0;27;1;0;1_`    | 0  | 27  | Esc | Down | 1  | 1  | Key Esc pressed       |
| `;0;91;1;0;1_`    | 0  | 91  | [   | Down | 1  | 1  | Key [ pressed         |
| `;0;50;1;0;1_`    | 0  | 50  | 2   | Down | 1  | 1  | Key 2 pressed         |
| `;0;48;1;0;1_`    | 0  | 48  | 0   | Down | 1  | 1  | Key 0 pressed         |
| `;0;48;1;0;1_`    | 0  | 48  | 0   | Down | 1  | 1  | Key 0 pressed         |
| `;0;126;1;0;1_`   | 0  | 126 | ~   | Down | 1  | 1  | Key ~ pressed         |
| `;4;20;116;1;0;1_`| 4  | 20  | t   | Down | 0  | 1  | Key t pressed         |
| `;4;20;116;0;0;1_`| 4  | 20  | t   | Up   | 0  | 1  | Key t released        |
| `;18;101;1;0;1_`  | 18 | 101 | e   | Down | 0  | 1  | Key e pressed         |
| `;18;101;0;0;1_`  | 18 | 101 | e   | Up   | 0  | 1  | Key e released        |
| `;3;31;115;1;0;1_`| 3  | 31  | s   | Down | 0  | 1  | Key s pressed         |
| `;3;31;115;0;0;1_`| 3  | 31  | s   | Up   | 0  | 1  | Key s released        |
| `;4;20;116;1;0;1_`| 4  | 20  | t   | Down | 0  | 1  | Key t pressed         |
| `;4;20;116;0;0;1_`| 4  | 20  | t   | Up   | 0  | 1  | Key t released        |
| `;0;27;1;0;1_`    | 0  | 27  | Esc | Down | 1  | 1  | Key Esc pressed       |
| `;0;91;1;0;1_`    | 0  | 91  | [   | Down | 1  | 1  | Key [ pressed         |
| `;0;50;1;0;1_`    | 0  | 50  | 2   | Down | 1  | 1  | Key 2 pressed         |
| `;0;48;1;0;1_`    | 0  | 48  | 0   | Down | 1  | 1  | Key 0 pressed         |
| `;0;49;1;0;1_`    | 0  | 49  | 1   | Down | 1  | 1  | Key 1 pressed         |
| `;0;126;1;0;1_`   | 0  | 126 | ~   | Down | 1  | 1  | Key ~ pressed         |

As you can see, there are much more key codes. Why?

Originally created by @ClusterM on GitHub (Aug 2, 2024). ### Windows Terminal version 1.21.1772.0 ### Windows build number 10.0.22631.3958 ### Other Software standard ssh, Linux ### Steps to reproduce 1. Copy "test" string to clipboard 2. Run Terminal 3. Connect to Linux via SSH 4. Type `printf "\x1b[?9001h"` to enable win32-input-mode 5. Right-click on the terminal window to paste text from a clipboard ### Expected Behavior `;4;20;116;1;0;1_;4;20;116;0;0;1_;18;101;1;0;1_;18;101;0;0;1_;3;31;115;1;0;1_;3;31;115;0;0;1_;4;20;116;1;0;1_;4;20;116;0;0;1_` It's `t`, `e`, `s`, `t` key presses. ### Actual Behavior `;0;27;1;0;1_;0;91;1;0;1_;0;50;1;0;1_;0;48;1;0;1_;0;48;1;0;1_;0;126;1;0;1_4;20;116;1;0;1_4;20;116;0;0;1_;18;101;1;0;1_;18;101;0;0;1_3;31;115;1;0;1_3;31;115;0;0;1_4;20;116;1;0;1_4;20;116;0;0;1_;0;27;1;0;1_;0;91;1;0;1_;0;50;1;0;1_;0;48;1;0;1_;0;49;1;0;1_;0;126;1;0;1_` Decoded: ``` | Sequence | Vk | Sc | Uc | Kd | Cs | Rc | Description | |-------------------|----|-----|-----|------|----|----|-----------------------| | `;0;27;1;0;1_` | 0 | 27 | Esc | Down | 1 | 1 | Key Esc pressed | | `;0;91;1;0;1_` | 0 | 91 | [ | Down | 1 | 1 | Key [ pressed | | `;0;50;1;0;1_` | 0 | 50 | 2 | Down | 1 | 1 | Key 2 pressed | | `;0;48;1;0;1_` | 0 | 48 | 0 | Down | 1 | 1 | Key 0 pressed | | `;0;48;1;0;1_` | 0 | 48 | 0 | Down | 1 | 1 | Key 0 pressed | | `;0;126;1;0;1_` | 0 | 126 | ~ | Down | 1 | 1 | Key ~ pressed | | `;4;20;116;1;0;1_`| 4 | 20 | t | Down | 0 | 1 | Key t pressed | | `;4;20;116;0;0;1_`| 4 | 20 | t | Up | 0 | 1 | Key t released | | `;18;101;1;0;1_` | 18 | 101 | e | Down | 0 | 1 | Key e pressed | | `;18;101;0;0;1_` | 18 | 101 | e | Up | 0 | 1 | Key e released | | `;3;31;115;1;0;1_`| 3 | 31 | s | Down | 0 | 1 | Key s pressed | | `;3;31;115;0;0;1_`| 3 | 31 | s | Up | 0 | 1 | Key s released | | `;4;20;116;1;0;1_`| 4 | 20 | t | Down | 0 | 1 | Key t pressed | | `;4;20;116;0;0;1_`| 4 | 20 | t | Up | 0 | 1 | Key t released | | `;0;27;1;0;1_` | 0 | 27 | Esc | Down | 1 | 1 | Key Esc pressed | | `;0;91;1;0;1_` | 0 | 91 | [ | Down | 1 | 1 | Key [ pressed | | `;0;50;1;0;1_` | 0 | 50 | 2 | Down | 1 | 1 | Key 2 pressed | | `;0;48;1;0;1_` | 0 | 48 | 0 | Down | 1 | 1 | Key 0 pressed | | `;0;49;1;0;1_` | 0 | 49 | 1 | Down | 1 | 1 | Key 1 pressed | | `;0;126;1;0;1_` | 0 | 126 | ~ | Down | 1 | 1 | Key ~ pressed | ``` As you can see, there are much more key codes. Why?
claunia added the Issue-BugArea-InputProduct-Conpty labels 2026-01-31 08:01:48 +00:00
claunia commented 2026-01-31 08:01:49 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 3, 2024):

So, the "press" and "release" for each key is expected. The encoding of \x1b[200~ (and ...201~) as Win32 key events is not entirely expected in normal cases.

However, you are requesting Win32 input mode as a client application. That means that all input generated for you from the console subsystem will be in INPUT_RECORD format.

You are getting the bracketed paste sequences \x1b[200~ and \x1b[201~ in the same way Windows applications using the ReadConsoleInput API do: VT, encoded as key presses.

We have work on the books to improve this (not translating VT sequences we generate when the application does not need them), but that is largely irrespective of Win32 input mode, and it is low priority because Windows applications already work this way.

TL;DR: When you request WIN32IM, you get the same kinds of input records as Console applications. That includes "key press" encodings for VT sequences. 😄

@DHowett commented on GitHub (Aug 3, 2024): So, the "press" and "release" for each key is expected. The encoding of `\x1b[200~` (and `...201~`) as Win32 key events is not entirely expected in normal cases. However, you are requesting Win32 input mode as a client application. That means that all input generated for you from the console subsystem will be in `INPUT_RECORD` format. You are getting the bracketed paste sequences `\x1b[200~` and `\x1b[201~` in the same way Windows applications using the `ReadConsoleInput` API do: VT, encoded as key presses. We have work on the books to improve this (not translating VT sequences we generate when the application does not need them), but that is largely irrespective of Win32 input mode, and it is low priority because Windows applications already work this way. TL;DR: When you request WIN32IM, you get the same kinds of input records as Console applications. That includes "key press" encodings for VT sequences. 😄
claunia commented 2026-01-31 08:01:49 +00:00
Author
Owner
Copy Link

@ClusterM commented on GitHub (Aug 3, 2024):

However, you are requesting Win32 input mode as a client application. That means that all input generated for you from the console subsystem will be in INPUT_RECORD format.

But I have only clean text in my clipboard and I want to paste it only. Terminal should enter this text as key presses and nothing else. This problem affects far2l:

image

And I'm not sure if it's far2l's bug or Terminal's bug.

@ClusterM commented on GitHub (Aug 3, 2024): > However, you are requesting Win32 input mode as a client application. That means that all input generated for you from the console subsystem will be in `INPUT_RECORD` format. But I have only clean text in my clipboard and I want to paste it only. Terminal should enter this text as key presses and nothing else. This problem affects [far2l](https://github.com/elfmz/far2l): ![image](https://github.com/user-attachments/assets/15340130-1e3a-4eac-b9f7-e95e3abcc44d) And I'm not sure if it's far2l's bug or Terminal's bug.
claunia commented 2026-01-31 08:01:49 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 3, 2024):

The win32-input-mode was primarily designed as a private 1 protocol between parts that make up Windows Terminal (ConPTY specifically). In that context it works perfectly, and this issue doesn't occur. The way I see it, it's a bug that clipboard pastes and VT sequences are encoded with the win32-input-mode format, because the spec explicitly says it's for keyboard input. I'd like to change this, but I'm not sure when I'd get to that.

I'm also a bit squirmish about working on this space, because I'm still concerned about claiming one of the very scarce terminators (_) and about future compatibility between systems of different versions and keyboard layouts. Personally, I'd prefer if applications could not request the win32-input-mode in the first place and it remained a strictly private protocol for the parts that make up Windows Terminal (and other terminals based on ConPTY). I know that various important applications have come to rely on this mode which makes me particularly worried, because I wonder now if it's too late to put a lid back onto this "leak". It's also not trivially possible to do so in the first place because ConPTY -> WSL -> ConPTY should work.

  1. "private" is a poor choice of words, as explained by Dustin below. ↩︎

@lhecker commented on GitHub (Aug 3, 2024): The win32-input-mode was primarily designed as a ~~private~~ [^1] protocol between parts that make up Windows Terminal (ConPTY specifically). In that context it works perfectly, and this issue doesn't occur. The way I see it, it's a bug that clipboard pastes and VT sequences are encoded with the win32-input-mode format, because the spec explicitly says it's for keyboard input. I'd like to change this, but I'm not sure when I'd get to that. I'm also a bit squirmish about working on this space, because I'm still concerned about claiming one of the very scarce terminators (`_`) and about future compatibility between systems of different versions and keyboard layouts. Personally, I'd prefer if applications could not request the win32-input-mode in the first place and it remained a strictly private protocol for the parts that make up Windows Terminal (and other terminals based on ConPTY). I know that various important applications have come to rely on this mode which makes me particularly worried, because I wonder now if it's too late to put a lid back onto this "leak". It's also not trivially possible to do so in the first place because ConPTY -> WSL -> ConPTY should work. [^1]: "private" is a poor choice of words, as explained by Dustin below.
claunia commented 2026-01-31 08:01:50 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 3, 2024):

private

I wouldn't call it private; it's just a protocol for high fidelity Console eventing that terminals on windows can use if they need to represent key make and break sequences.

Terminal should enter this text as key presses and nothing else.

It is. But Windows console applications don't actually read text, they read true key press and release events, even when they are reading VT. There is a bug today where the key press and release events we synthesize for VT are re-encoded as Win32-input-mode events even when the application has indicated that it wants direct VT input.

I'm not talking about our ideal state, just what we have today.

What we have today has some gaps because it was not designed to be an application-facing protocol. That's fine; if we want to make it one we can fix the bugs and pursue standardization.

@DHowett commented on GitHub (Aug 3, 2024): > private I wouldn't call it private; it's just a protocol for high fidelity Console eventing that terminals on windows *can* use if they need to represent key make and break sequences. > Terminal should enter this text as key presses and nothing else. It is. But Windows console applications don't actually read text, they read true key press and release events, even when they are reading VT. There is a bug today where the key press and release events we synthesize for VT are re-encoded as Win32-input-mode events even when the application has indicated that it wants direct VT input. I'm not talking about our ideal state, just what we have today. What we have today has some gaps because it was not designed to be an application-facing protocol. That's fine; if we want to make it one we can fix the bugs and pursue standardization.
claunia commented 2026-01-31 08:01:50 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 3, 2024):

And I'm not sure if it's far2l's bug

Thinking about this more: if the shell inside far2l is requesting bracketed paste mode, and far2l is requesting Win32 input mode, then regardless of how the escape sequences are translated I would expect far2l to unencapsulate them. That's what Windows console applications do, when they get them in INPUT_RECORD format (which is the Windows API equivalent.)

I'm not closing this and saying we won't fix it, but far2l's translation layer could be better as well.

@DHowett commented on GitHub (Aug 3, 2024): > And I'm not sure if it's far2l's bug Thinking about this more: if the shell inside far2l is requesting bracketed paste mode, and far2l is requesting Win32 input mode, then regardless of how the escape sequences are translated I would expect far2l to unencapsulate them. That's what Windows console applications do, when they get them in INPUT_RECORD format (which is the Windows API equivalent.) I'm not closing this and saying we won't fix it, but far2l's translation layer could be better as well.
claunia commented 2026-01-31 08:01:50 +00:00
Author
Owner
Copy Link

@atolismesh commented on GitHub (Aug 3, 2024):

I think that this issue is more complex.
Details are here -· Issue ·https://github.com/microsoft/terminal/issues/15083#issuecomment-2002509760
"I looked in the WinDbg debugger to see what was going on. ..... "

@atolismesh commented on GitHub (Aug 3, 2024): I think that this issue is more complex. Details are here -· Issue ·https://github.com/microsoft/terminal/issues/15083#issuecomment-2002509760 "I looked in the WinDbg debugger to see what was going on. ..... "
claunia commented 2026-01-31 08:01:50 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 3, 2024):

Thanks for finding that! It's fundamentally the same issue. Once one of us is back in the office we'll deduplicate them and migrate all the relevant data over.

@DHowett commented on GitHub (Aug 3, 2024): Thanks for finding that! It's fundamentally the same issue. Once one of us is back in the office we'll deduplicate them and migrate all the relevant data over.
claunia commented 2026-01-31 08:01:51 +00:00
Author
Owner
Copy Link

@ClusterM commented on GitHub (Aug 5, 2024):

I'm not closing this and saying we won't fix it, but far2l's translation layer could be better as well.

Yes, it was terrible. I fixed it, waiting for pull request merge :)

@ClusterM commented on GitHub (Aug 5, 2024): > I'm not closing this and saying we won't fix it, but far2l's translation layer could be better as well. Yes, it was terrible. I fixed it, waiting for pull request merge :)
claunia commented 2026-01-31 08:01:51 +00:00
Author
Owner
Copy Link

@unxed commented on GitHub (Oct 7, 2024):

I'm not closing this and saying we won't fix it, but far2l's translation layer could be better as well.

Am I correct in understanding that pull request #17833 solves this problem too?

@DHowett

@unxed commented on GitHub (Oct 7, 2024): > I'm not closing this and saying we won't fix it, but far2l's translation layer could be better as well. Am I correct in understanding that pull request #17833 solves this problem too? @DHowett
claunia commented 2026-01-31 08:01:51 +00:00
Author
Owner
Copy Link

@gdamore commented on GitHub (Jul 10, 2025):

One note on the issue of win32-im being "private".

The problem I see is that the Windows event subsystem provides (mostly) a richer experience than the legacy ANSI console supported by VtInput mode (ironically the opposite is true for output mode -- VtOutput mode is far richer than the legacy Windows output mode.)

There was a request to support the Kitty protocol, which IMO would go far towards helping applications move away from win32-im -- but until we have a way to receive key presses that are unambiguous (which legacy ANSI mode cannot do for historical reasons -- Control-I and TAB are the same encoding for example) I don't see another immediate solution.

Today I learned that I can at least receive the bracketed paste keys although it will require some extra effort for me to decode which the Windows side of my application currently does not have to do. That's ok I suppose.

@gdamore commented on GitHub (Jul 10, 2025): One note on the issue of win32-im being "private". The problem I see is that the Windows event subsystem provides (mostly) a richer experience than the legacy ANSI console supported by VtInput mode (ironically the opposite is true for output mode -- VtOutput mode is far richer than the legacy Windows output mode.) There was a request to support the Kitty protocol, which IMO would go far towards helping applications move away from win32-im -- but until we have a way to receive key presses that are unambiguous (which legacy ANSI mode cannot do for historical reasons -- Control-I and TAB are the same encoding for example) I don't see another immediate solution. Today I learned that I can at least receive the bracketed paste keys although it will require some extra effort for me to decode which the Windows side of my application currently does not have to do. That's ok I suppose.
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 Area-Input Issue-Bug Product-Conpty
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#22042
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?