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

Feature request: Pasting with OSC 52 (for e.g. terminal-based editors) #13008

New Issue
Open
opened 2026-01-31 03:31:17 +00:00 by claunia · 16 comments
claunia commented 2026-01-31 03:31:17 +00:00
Owner
Copy Link

Originally created by @alexrp on GitHub (Mar 13, 2021).

Related: #2946, #5823

It seems like a decision was made not to support pasting due to security concerns. This is understandable of course, but considering there are editors (such as micro) that actually use this functionality, it's also a bit disappointing.

Perhaps a middle ground would be to have the support but require the user to opt in in Windows Terminal settings?

FWIW, > help copypaste in micro gives this useful info:

* Kitty: supported, but only writing is enabled by default. To enable
  reading, add `read-primary` and `read-clipboard` to the
  `clipboard_control` option.

* iTerm2: only copying (writing to clipboard) is supported. Must be enabled in
  `Preferences->General-> Selection->Applications in terminal may access clipboard`.
  You can use Command-v to paste.

* `st`: supported.

* `rxvt-unicode`: not natively supported, but there is a Perl extension
   [here](http://anti.teamidiot.de/static/nei/*/Code/urxvt/).

* `xterm`: supported, but disabled by default. It can be enabled by putting
   the following in `.Xresources` or `.Xdefaults`:
   `XTerm*disallowedWindowOps: 20,21,SetXprop`.

* `gnome-terminal`: does not support OSC 52.
Originally created by @alexrp on GitHub (Mar 13, 2021). Related: #2946, #5823 It seems like a decision was made not to support pasting due to security concerns. This is understandable of course, but considering there are editors (such as `micro`) that actually use this functionality, it's also a bit disappointing. Perhaps a middle ground would be to have the support but require the user to opt in in Windows Terminal settings? FWIW, `> help copypaste` in `micro` gives this useful info: ``` * Kitty: supported, but only writing is enabled by default. To enable reading, add `read-primary` and `read-clipboard` to the `clipboard_control` option. * iTerm2: only copying (writing to clipboard) is supported. Must be enabled in `Preferences->General-> Selection->Applications in terminal may access clipboard`. You can use Command-v to paste. * `st`: supported. * `rxvt-unicode`: not natively supported, but there is a Perl extension [here](http://anti.teamidiot.de/static/nei/*/Code/urxvt/). * `xterm`: supported, but disabled by default. It can be enabled by putting the following in `.Xresources` or `.Xdefaults`: `XTerm*disallowedWindowOps: 20,21,SetXprop`. * `gnome-terminal`: does not support OSC 52. ```
claunia commented 2026-01-31 03:31:19 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 15, 2021):

Well, there sure does seem like a lot of precedent for a setting that enables this behavior, when it's disabled by default. I can dig that. "Applications in terminal may access clipboard" sounds good to me, but we'll need to find something more succinct than that for the actual setting.

I'm thinking that this should be a per-profile, control-level setting.

Thanks!

@zadjii-msft commented on GitHub (Mar 15, 2021): Well, there sure does seem like a lot of precedent for a setting that enables this behavior, when it's disabled by default. I can dig that. "Applications in terminal may access clipboard" sounds good to me, but we'll need to find something more succinct than that for the actual setting. I'm thinking that this should be a per-profile, control-level setting. Thanks!
claunia commented 2026-01-31 03:31:19 +00:00
Author
Owner
Copy Link

@thiagowfx commented on GitHub (Oct 7, 2021):

Also related: https://github.com/microsoft/vscode/issues/104138

@thiagowfx commented on GitHub (Oct 7, 2021): Also related: https://github.com/microsoft/vscode/issues/104138
claunia commented 2026-01-31 03:31:19 +00:00
Author
Owner
Copy Link

@rsprabery commented on GitHub (Jan 6, 2022):

This would be great. +1.

@rsprabery commented on GitHub (Jan 6, 2022): This would be great. +1.
claunia commented 2026-01-31 03:31:19 +00:00
Author
Owner
Copy Link

@rsprabery commented on GitHub (Jan 6, 2022):

This would be great. +1.

Copying text from tmux via OSC 52 is a common workflow and muscle memory always leaves me surprised when I paste something I didn't didn't just copy via tmux.

Wasn't sure where to upvote as it looks like linked bugs were closed.

@rsprabery commented on GitHub (Jan 6, 2022): This would be great. +1. Copying text from tmux via OSC 52 is a common workflow and muscle memory always leaves me surprised when I paste something I didn't didn't just copy via tmux. Wasn't sure where to upvote as it looks like linked bugs were closed.
claunia commented 2026-01-31 03:31:19 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 7, 2022):

Wasn't sure where to upvote as it looks like linked bugs were closed.

image

@zadjii-msft commented on GitHub (Jan 7, 2022): > Wasn't sure where to upvote as it looks like linked bugs were closed. ![image](https://user-images.githubusercontent.com/18356694/148471563-0d876ca9-69f3-4215-809d-39e6920b7919.png)
claunia commented 2026-01-31 03:31:19 +00:00
Author
Owner
Copy Link

@sibouras commented on GitHub (Feb 9, 2025):

after setting guiapplications = false in .wslconfig wl-clipboard and xclip no longer work so terminal text editors like nvim and helix fallback to win32yank.exe which is slow to start and pasting is visibly laggy. pasting with osc 52 is the solution to this problem.

@sibouras commented on GitHub (Feb 9, 2025): after setting `guiapplications = false` in .wslconfig `wl-clipboard` and `xclip` no longer work so terminal text editors like nvim and helix fallback to `win32yank.exe` which is slow to start and pasting is visibly laggy. pasting with osc 52 is the solution to this problem.
claunia commented 2026-01-31 03:31:20 +00:00
Author
Owner
Copy Link

@ni554n commented on GitHub (Jun 25, 2025):

after setting guiapplications = false in .wslconfig wl-clipboard and xclip no longer work so terminal text editors like nvim and helix fallback to win32yank.exe which is slow to start and pasting is visibly laggy. pasting with osc 52 is the solution to this problem.

My slow paste startup issue was resolved by https://github.com/neovim/neovim/issues/33716

@ni554n commented on GitHub (Jun 25, 2025): > after setting `guiapplications = false` in .wslconfig `wl-clipboard` and `xclip` no longer work so terminal text editors like nvim and helix fallback to `win32yank.exe` which is slow to start and pasting is visibly laggy. pasting with osc 52 is the solution to this problem. My slow paste startup issue was resolved by https://github.com/neovim/neovim/issues/33716
claunia commented 2026-01-31 03:31:20 +00:00
Author
Owner
Copy Link

@jemiller0 commented on GitHub (Oct 31, 2025):

I think this is already implemented and Microsoft Edit uses it?

@jemiller0 commented on GitHub (Oct 31, 2025): I think this is already implemented and Microsoft Edit uses it?
claunia commented 2026-01-31 03:31:20 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 31, 2025):

Nah. Edit uses the much less controversial "write to clipboard" part of OSC 52. When you paste into edit from outside, it requests bracketed paste (so it knows when the paste begins and ends,) but it does not read the clipboard directly (which is the request here!)

@DHowett commented on GitHub (Oct 31, 2025): Nah. Edit uses the much less controversial "write to clipboard" part of `OSC 52`. When you paste into edit from outside, it requests bracketed paste (so it knows when the paste begins and ends,) but it does not *read the clipboard directly* (which is the request here!)
claunia commented 2026-01-31 03:31:20 +00:00
Author
Owner
Copy Link

@jemiller0 commented on GitHub (Oct 31, 2025):

Is there a way to make copy/paste work with Gnome Terminal so that it uses the system clipboard and you can copy/paste to/from other applications? As far as I can tell, this doesn't presently work.

@jemiller0 commented on GitHub (Oct 31, 2025): Is there a way to make copy/paste work with Gnome Terminal so that it uses the system clipboard and you can copy/paste to/from other applications? As far as I can tell, this doesn't presently work.
claunia commented 2026-01-31 03:31:20 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 31, 2025):

I'm sorry, that's out of scope for the Windows Terminal repository. I can only offer that the maintainers of libvte (which control powers gnome-terminal) have taken a position against clipboard operations.

@DHowett commented on GitHub (Oct 31, 2025): I'm sorry, that's out of scope for the Windows Terminal repository. I can only offer that the maintainers of libvte (which control powers gnome-terminal) have taken a position against clipboard operations.
claunia commented 2026-01-31 03:31:21 +00:00
Author
Owner
Copy Link

@jemiller0 commented on GitHub (Oct 31, 2025):

Oh sorry, I meant to post this on a different issue I was looking at for Edit.

@jemiller0 commented on GitHub (Oct 31, 2025): Oh sorry, I meant to post this on a different issue I was looking at for Edit.
claunia commented 2026-01-31 03:31:21 +00:00
Author
Owner
Copy Link

@ofek commented on GitHub (Jan 24, 2026):

Users of Nushell are also affected by this in that one cannot paste from the clipboard, only copy to it.

Would it be acceptable to have an option like this comment proposed?

Well, there sure does seem like a lot of precedent for a setting that enables this behavior, when it's disabled by default. I can dig that. "Applications in terminal may access clipboard" sounds good to me, but we'll need to find something more succinct than that for the actual setting.

@ofek commented on GitHub (Jan 24, 2026): Users of Nushell are also [affected](https://github.com/nushell/nushell/issues/16242) by this in that one cannot paste from the clipboard, only copy to it. Would it be acceptable to have an option like [this comment](https://github.com/microsoft/terminal/issues/9479#issuecomment-799359673) proposed? > Well, there sure does seem like a lot of precedent for a setting that enables this behavior, when it's disabled by default. I can dig that. "Applications in terminal may access clipboard" sounds good to me, but we'll need to find something more succinct than that for the actual setting.
claunia commented 2026-01-31 03:31:21 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 24, 2026):

Is there any reason why you don't just use the terminal's built in paste functionality, which is both faster and more secure? Why does the shell need to request the paste itself?

@j4james commented on GitHub (Jan 24, 2026): Is there any reason why you don't just use the terminal's built in paste functionality, which is both faster and more secure? Why does the shell need to request the paste itself?
claunia commented 2026-01-31 03:31:21 +00:00
Author
Owner
Copy Link

@ofek commented on GitHub (Jan 25, 2026):

I already use the terminal's built-in paste functionality when I want to actually send the contents of my clipboard. The reason I want this feature is to process the contents of my clipboard e.g. clipboard copy arbitrary JSON and send it to jq.

@ofek commented on GitHub (Jan 25, 2026): I already use the terminal's built-in paste functionality when I want to actually send the contents of my clipboard. The reason I want this feature is to process the contents of my clipboard e.g. clipboard copy arbitrary JSON and send it to `jq`.
claunia commented 2026-01-31 03:31:21 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 25, 2026):

I assume that means the shell (or whatever requested the clipboard contents) will need to wait for the response from the terminal, so it can pass that content on to jq. Is that correct?

The reason I'm asking is because the typical way to secure clipboard read access (short of turning it off completely) is to have the user confirm the operation when it receives an OSC 52 paste request. But that means the app will likely time out if it is waiting for the response, and assume the terminal just doesn't support the operation. To make matters worse, when the content does eventually arrive, you can end up with a bunch of garbage dumped into the command line.

We could also have an option to turn off that confirmation, but that's a big security risk for users that may not understand the implication of that action. Maybe not a problem for users that only work locally, but in that case the app could have just read from the clipboard directly.

@j4james commented on GitHub (Jan 25, 2026): I assume that means the shell (or whatever requested the clipboard contents) will need to wait for the response from the terminal, so it can pass that content on to `jq`. Is that correct? The reason I'm asking is because the typical way to secure clipboard read access (short of turning it off completely) is to have the user confirm the operation when it receives an `OSC 52` paste request. But that means the app will likely time out if it is waiting for the response, and assume the terminal just doesn't support the operation. To make matters worse, when the content does eventually arrive, you can end up with a bunch of garbage dumped into the command line. We could also have an option to turn off that confirmation, but that's a big security risk for users that may not understand the implication of that action. Maybe not a problem for users that only work locally, but in that case the app could have just read from the clipboard directly.
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-Settings Area-TerminalControl Help Wanted Issue-Task Product-Terminal
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#13008
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?