[Feat]: clipboard support

[smerschjohann]

What is your suggestion?

On linux (and WSL2), I like to use clipboard utilities to paste the stdout of a process to the clipboard.

Like the following:

date | xclip -selection clipboard 

It would be great if the code-server would have a functionality like code-server clipboard or something similiar.

I'm currently looking into that problem, but cannot find a way to execute javascript code (directly or by RPC call) in the browser session from the "emulated" terminal.

I want to use the navigator.clipboard.writeText function for that.

Why do you want this feature?

I want to use it to auto copy auto generated URLs, identifiers, passwords etc.

Are there any workarounds to get this functionality today?

Select the output of the application, press CTRL+SHIFT+C.

But that is cumbersome and also in case of passwords, prints the passwords to the terminal which has to be cleared afterwards.

Are you interested in submitting a PR for this?

In general, yes, but I think a solution needs to be discussed first.

[code-asher]

That would be cool! It could maybe be implemented through an extension using the env.clipboard API but having it baked into VS Code would be neat. It even seems like something that might be accepted upstream if we wanted to try doing it there directly rather than patching here in code-server.

[smerschjohann]

Yes, using that API should work. I don't really know if there is really a way to do it as a VS Extension. It would be possible to use the Files-API. So write to a file, monitor that file and read the content to the clipboard. But other than that, I cannot find a way to call an extension or anything else from the command line. Do you know a way here?

So it would be best to directly integrate either a "trigger {extension) command from command line" or just a "pipe to clipboard from command line" functionality. The first would have the charm, that other implementations can benefit from that as well. But I'm not sure if we would need some kind of whitelisting for security reasons.

Regarding upstream vs Code-Server: You are right, that feature would be great for the "Remote" functionality of VSCode as well. So we could try bring it to upstream as well. But how difficult is it? Maybe start here and bring it upstream afterwards?

[code-asher]

Yeah that is pretty much what I was thinking, a file that is either a socket or a pipe but then you would have to do things like echo test > /path/to/socket which is unfortunate. The extension could provide a script/binary that you install which would do this for you, call it code-server-xclip or something and use it like echo test | code-server-xclip.

I know you can trigger extensions with something like code-server --open vscode://extension-id/some/path (I might have the syntax a bit wrong) but I think it does not support stdin so that would not be super useful, plus it is unfortunate that you would have to know the extension ID. We could add stdin support.

But the more I think about it the more it seems like this should just be in the core.

Difficulty for actual implementation should be similar either way. The main downside I see to doing it here first is that upstream might have better ideas on how to implement and we risk having to completely redo it. Also our resources are limited so the less we have to maintain here the better.

[smerschjohann]

Ok I think I figured out how to add it as a command. As it turns out, it is not possible to accomplish the goal without either the files quirk, some other dirty hacks like injecting code in the index.html completly skipping "code-server" or a direct integration in the core. So I would go for the core ...

To do that, we need to add it here: https://github.com/microsoft/vscode/blob/2c73d2651cc525b27fc697b820743098a204ec01/src/vs/workbench/contrib/terminal/browser/remoteTerminalBackend.ts#L91 and add it as a new CLI Command

To test it at first, I can use curl (of course replaced with the new type):

curl --unix-socket $VSCODE_IPC_HOOK_CLI \
     -H "Content-Type: application/json" -X POST \
     -d '{"type":"extensionManagement", "list": {"showVersions": true}}' \
     http://localhost

But I struggle a little bit to setup a dev environment. I followed the description. yarn and yarn watch works so far, but the browser prints ENOENT: no such file or directory, open '/home/coder/dev/code-server/lib/vscode/out/vs/server/node/server.main.js'. What am I missing here? I would like to do it as a little prove of concept. After it works in code-server, I can still try to bring it to VSCode directly.

[code-asher]

Nice!

That ENOENT usually means VS Code is still compiling (really bad error, we should fix it). Once you see something like

[Code OSS] [watch-client    ] [14:40:53] Finished compilation with 0 errors

then you should be good to go.

[smerschjohann]

Ah thanks, I did not wait enough but also my fs notify watch limit was not high enough.

I have it working now: https://github.com/coder/code-server/compare/main...smerschjohann:code-server:main

You can try by:

curl --unix-socket $VSCODE_IPC_HOOK_CLI \
     -H "Content-Type: application/json" -X POST \
     -d '{"type":"clipboard", "content": "great it works"}' \
     http://localhost

next you will have the content in your clipboard 👍

Next step: Check how to integrate it in the CLI utility.

[smerschjohann]

It's in the the CLI now as well. Turns out, I did not touch any code-server code after all :D

You can try with a dev build and a patched code-server cli script:

#!/usr/bin/env sh
#
# Copyright (c) Microsoft Corporation. All rights reserved.
#
# PATCH to DEV path
VSROOT=/home/coder/dev/code-server/lib/vscode
ROOT="$(dirname "$(dirname "$VSROOT")")"

APP_NAME="code-server"
VERSION="1.77.3"
COMMIT="704ed70d4fd1c6bd6342c436f1ede30d1cff4710"
EXEC_NAME="code-server"
CLI_SCRIPT="$VSROOT/out/server-cli.js"
"${NODE_EXEC_PATH:-$ROOT/lib/node}" "$CLI_SCRIPT" "$APP_NAME" "$VERSION" "$COMMIT" "$EXEC_NAME" "$@"

and use it like this:

echo -n my cipboard text | ./code-server --clipboard

Cool. Do you think it makes sense this way? Then I would try opening an issue and PR on vscode ..

Anyway, it would be cool to have it in the meantime already in code-server. ;)

[smerschjohann]

I opened an issue + PR upstream: https://github.com/microsoft/vscode/issues/181724

[code-asher]

Awesome!!!

[smerschjohann]

So it is in backlog candidates now which means we need at least 20 upvotes that it will be considered.

So if you want to see this in VSCode, code-server etc. please upvote it here by giving a thumbs up: https://github.com/microsoft/vscode/issues/181724

[bdsoha]

@smerschjohann Is there a way to try again?

[smerschjohann]

@bdsoha You can try, I would vote for it. But maybe it has more chance of success, if the feature would be something that allows generic passing data to extensions in VSCode or something. Then we could implement it on our own or we really integrate it just in code-server...

In the meantime, I use it this way, that is not as good as my suggestion, but at least is something:

1. Make an alias like this:

alias xclip="tr -d '\n' | code-server -; rm /tmp/code-stdin-*"

2. usage

echo -n test | xclip

3. This will open a new editor tab in code-server and allow you to copy from that. CTRL+A, CTRL+C, CTRL+W
4. It will also delete the temporary files after it is done. Otherwise the temporary files will be kept indefinitely which could potentially include security relevant data .. another issue that got just ignored in their issue tracker.

[smerschjohann]

@code-asher I would really like to have this feature. It seems Microsoft / VSCode is not interested, so as I already had a PR running for code-server and vscode, would it be possible that I reopen it, clean it up and do any changes that might be required?

There are some tools that really rely on the clipboard e.g. gh copilot suggest. The password/secrets use case also still applies.

[code-asher]

It does seem pretty useful, and looks low-maintenance. If you reopen it we will get it merged in.

[smerschjohann]

@code-asher ok, I created a new branch and PR and applied the change to the current main.

I also changed the parameter from just --clipboard to --stdin-to-clipboard, the shorthand -c remains. This describes the purpose a little bit better.