forward clipboard read osc sequence

[theimpostor]

It appears that reading the clipboard via osc is not supported yet. Can it be added? Many terminals have added support for this, either by default (e.g. alacritty) or gated behind a config option (iterm2, kitty). Passing through the clipboard read command and allowing the terminal to handle/reject seems like it would be useful.

[whmountains]

#2637, opened 5 days earlier, is closely related to this. Having the ability to paste into a Zellij session would be very helpful for those of us who "literally live in the remote session."

[Lockszmith-GH]

osc is a clipboard tool for the modern age, since August is explicitly excluding Zellij due to incompatibility - links to this issue on the README.md page.

This is a shame, as this is the only non-server based clipboard stdin/stdout app I've found.

If no one can spare the time to take a look at it, I would appricate some guidance at to how this would be tackled.

Some general pointers, and I'd be willing to attempt a PR for this.

[imsnif]

Zellij intentionally does not support the paste part of OSC52, just the copy part.

Why? Think about everything you're copying to your clipboard (intentionally or unintentionally through just marking it in some DEs). Now imagine anything you run through your terminal (intentionally or unintentionally) would be able to read this clipboard without you even noticing it happened.

Would you be comfortable with that? Neither would I. I'm so uncomfortable with it that I don't even want software that I maintain to have this ability.

I realize this can be very convenient and empathize with users who want this, but this is IMO too reckless to have in any sort of terminal.

I might consider adding it behind a user visible prompt (eg. program <X> wants to read this text <TEXT> from your clipboard, allow? (y/n))

[jshu-git]

Chiming in here since I've been looking forward to this too for a while. To preface, I have been daily driving with zellij at work since its release, and it has replaced (almost all of) tmux for and I don't see myself ever going back. (I also use neovim with clipboard='unnamedplus').

I use zellij through remote ssh sessions at work, and the lack of support for the paste event is an area where I still encounter some friction (albeit, a small amount) in daily work. When swapping between many zellij tabs with neovim open in all of them, copying text between them is simple (just yank to the system clipboard). However, when pasting text between them, I have to remember to paste not with p or P, but with cmd-v. Sometimes I still paste with p out of habit and have to undo the paste and paste again. This can be particularly annoying when I meant to paste over selected text and I forget that I can't use p, so I have to reselect what I wanted to paste over again.

Based on discussion in other issues (#2637 #3135), the first workaround is to use neovim's built-in OSC52 clipboard (as of 0.10.0). However, if you try to paste with p, neovim will stall with Waiting for OSC 52 response from the terminal. Press Ctrl-C to interrupt... before timing out (since paste event is unsupported by zellij). So I have found the actual workaround is to use the nvim-osc52 plugin, which gives the functionality in my earlier example (copy with yank, paste with cmd-v). One thing to note is this plugin links to the osc page that has a table comparing osc functionality between different terminal multiplexers). zellij is the only one that does not support the paste event (with a link to this issue). (This is one of the only things I still miss from tmux)

I agree this functionality should not be left on by default but having it at least as an option makes sense to me. If it is on, there could be the user visible prompt like you mentioned (on by default, and can be turned off). I believe ghostty already has something like this called clipboard-paste-protection.

[imsnif]

Good to hear from one of the Zellij elders :)

I'm happy to accept a contribution for this with the pop-up. I would encourage anyone interested in implementing this to consult me first, as I'd like to have the pop-up implemented as a custom built-in notification plugin (so that we can also use it for other stuff and allow users to swap it for custom implementations).

[ToxicFrog]

I agree this functionality should not be left on by default but having it at least as an option makes sense to me. If it is on, there could be the user visible prompt like you mentioned (on by default, and can be turned off). I believe ghostty already has something like this called clipboard-paste-protection.

Ghostty and Kitty both have this as an option, yeah -- "reject paste", "prompt user on every paste", or "always paste".

tmux is somewhat different here (and osc's support for it is correspondingly complicated). On OSC52 paste, it will (depending on configuration) ignore it, forward the sequence to the client, or forward to the client and set one of its internal paste buffers. On OSC52 paste, it will always paste from its internal buffers and never forward the request to the client.

osc handles this by wrapping the copy command in a tmux passthrough sequence, allowing it to go straight to the host without touching tmux's paste buffers, and then on paste, calling tmux refresh-client -l to request the clipboard from the client -- at which point it's up to the client terminal what it does (e.g. prompt the user if using ghostty/kitty, unconditionally reject if using konsole, etc).

This does seem to contradict the osc documentation -- it doesn't look like it needs set-clipboard permission -- but possibly there's some subtlety there I'm missing.

At any rate, this is a source of some recurring confusion when trying to use OSC52 with tmux, because even if everything is configured "right", you'll end up copying into your local clipboard and the tmux clipboard, but only ever pasting from the tmux clipboard, which is fine for copy-paste within a tmux session but doesn't do what you want if you're trying to copy from something else into it; and the workaround is to explicitly run tmux refresh-client -l before each paste, which requires special tmux handling in every program. :(

[JohnAntoine]

I can totally understand the security implications. However, adding a notification every time something needs to read the clipboard through OSC adds friction and an unnecessary extra step in an environment where the main draw is speed and efficiency. Instead, making the feature (OPT-IN) with a giant disclaimer in the docs is a suitable middle ground. Putting the power in the hands of the user, given that the user is suitably informed, is never a bad thing.

[imsnif]

I can totally understand the security implications. However, adding a notification every time something needs to read the clipboard through OSC adds friction and an unnecessary extra step in an environment where the main draw is speed and efficiency. Instead, making the feature (OPT-IN) with a giant disclaimer in the docs is a suitable middle ground. Putting the power in the hands of the user, given that the user is suitably informed, is never a bad thing.

I'm happy to add a "never show again" checkbox to said pop-up. But for the record, while I think allowing the user to do this with giant warnings is good to remove the responsibility from the maintainers, it's still a terrible idea from the user's perspective. I'm honestly a bit surprised we haven't seen more attacks from this vector, but I have a feeling we will in the future.

Anyway, just my opinion. Since many terminals support this without even showing any pop-up or warning, it won't be the end of the world if we do it this way.