YEyencabulator·Feb 8, 2025
In VSCode’s SSH agent is bananasmicrosoft
vscode-remote-release
Dockerfile2019–2026
microsoft / vscode-remote-release
vscode-remote-release
Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
20Distinct people
26Mentions
1Explicit recommenders
4.2KGitHub stars
What to know before exploring
What it is
Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Kind of. A vscode workspace can trivially execute code on the machine that runs the server end of vscode. (This is how building works -- there is no sandbox unless the…
amluto used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:01:02 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year26 dated mentions
Observed mentions: 2019-05-06 20:28:11 UTC to 2026-06-10 16:43:14 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 2 | 2 |
What Hacker News says
5 sources"For VS Code remote, the VS Code server is in the same trust boundary as the VS Code client. [...]
For Remote SSH: [...] A compromised remote could use the VS Code Remote connection to execute code on your local machine."
https://github.com/microsoft/vscode-remote-release/issues/66...
I wrote about it in a bit more detail a month ago because it seems to be a common misunderstanding: "VS Code Remote Dev and Dev Containers are not security boundaries" https://lets.re/blog/vscode-remote-dev/
In VSCode’s SSH agent is bananasNot OP, but I've been trying to get remote development working for years but to no avail. The official response on the GitHub issue [0] in 2019 was:
> The "remote" functionality (SSH/WSL/Docker) is currently only available for VS Code proper, not 3rd party builds.
> [...] /cc @joaomoreno
Last time I checked, Arch Linux users who have the Arch Linux build of VS Code installed still cannot use remote SSH development nor dev containers. I definitely can't get it working on my own development machines.
[0]: https://github.com/microsoft/vscode-remote-release/issues/17...
In VSCode’s SSH agent is bananas> VSCode appropriately partitions responsibilities between the local and the remote, automatically restores IDE infrastructure on the remote as needed, and enforces the partitioning architecturally for all extensions.
Excuse me? This:
https://github.com/microsoft/vscode-remote-release/issues/66...
Is the opposite of architecturally enforced appropriate partitioning. This is “we want to make it convenient to use, and we do not care about security or enforcement of the local vs remote split at all.”
In VSCode’s SSH agent is bananasVSCode’s entire security model is bananas. As far as I can tell:
The client and its scripts and plugins get unrestricted access to the remote system.
The code you’re editing (if not in restricted mode) gets full access to the system it’s on (which is IMO an unfortunate default but not surprising — it’s really time for development systems to wake up and sandbox the code being developed to at least be limited to its own directory tree, but that’s a different story).
The code you’re editing (if not in restricted mode) and remote plugins (no prompt at all AFAICT) get effectively full access to the client system, subject only to whatever privileges the client itself has. Yes, you read that right, if you Remote-SSH into a machine, that machine immediately owns you. Microsoft knows, and they do not care.
See, for example, https://github.com/mi