HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
microsoft
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
REPOSITORY AT A GLANCE

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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM 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.

0123452019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments. Incomplete calendar period.2026*

* 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
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC514
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC303
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC404
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC110
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC505
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC422

What Hacker News says

26 sources
Sure! Side note: Unfortunately VSCode devcontainers aren't open source and do not work with VSCodium. Upvote if you'd like VSCode devcontainers open sourced. [1] This example should still work with VSCode though. And the devcontainer CLI. Also, Zed has some issues around Podman and SELinux with an open PR. [2] And unfortunately Podman Compose does not currently work with Flatpak Zed. [3] In Zed to enable Podman, add the following to Zed 'settings.json': "use_podman": true Then we're just mostly following the guide: https://containers.dev/guide/dockerfile Create '.devcontainer/devcontainer.json': { "name": "projectName", "runArgs": ["--name", "projectName"], "dockerComposeFile": "docker-compose.yml", "service": "devcontainer", "features": { "ghcr.io/devcontainers/features/nix:1": { "packages": "devenv
Read the rest
" } }, "workspaceFolder": "/workspaces/${localWorkspaceFolderBasename}", "onCreateCommand": "nix-env -iA nixpkgs.devenv", "postCreateCommand": "git config --global user.name \"${GIT_USER_NAME}\" && git config --global user.email \"${GIT_USER_EMAIL}\" && git config --global --add --bool push.autoSetupRemote true && echo 'eval \"$(devenv hook bash)\"' | tee -a ~/.bashrc" // If compose isn't needed use the following: // "image": "mcr.microsoft.com/devcontainers/base:debian", // "containerEnv": { // "GIT_USER_NAME": "${localEnv:GIT_USER_NAME}", // "GIT_USER_EMAIL": "${localEnv:GIT_USER_EMAIL}", // "SSH_AUTH_SOCK": "/run/host-services/ssh-auth.sock", // }, // "mounts": [ // "source=${localEnv:XDG_RUNTIME_DIR}/ssh-agent.socket,target=/run/host-services/ssh-auth.sock,type=bind", // ], } Then create '.devcontainer/docker-compose.yml': name: projectName services: devcontainer: image: mcr.microsoft.com/devcontainers/base:debian command: sleep infinity userns_mode: keep-id environment: SSH_AUTH_SOCK: /run/host-services/ssh-auth.sock GIT_USER_EMAIL: ${GIT_USER_EMAIL?err} GIT_USER_NAME: ${GIT_USER_NAME?err} POSTGRES_DB: ${POSTGRES_DB:-projectName} POSTGRES_USER: ${POSTGRES_USER:-postgres} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-postgres} ports: # To connect to postgres running inside the container - target: 5432 published: 5432 protocol: tcp host_ip: 127.0.0.1 mode: host volumes: - ${XDG_RUNTIME_DIR}/ssh-agent.socket:/run/host-services/ssh-auth.sock:bind - ..:/workspaces/projectName:cached And lastly create 'devenv.nix': { pkgs, config, ... }: { env.GREET = "determinism"; enterShell = '' echo hello ${config.env.GREET} ''; packages = [ pkgs.nodejs pkgs.yarn ]; services = { postgres = { enable = true; listen_addresses = "0.0.0.0"; hbaConf = '' # TYPE DATABASE USER ADDRESS METHOD local all all peer host all all 127.0.0.1/32 trust host all all 0.0.0.0/0 md5 ''; initialDatabases = [ { name = "postgres"; } { name = "projectName"; } { name = "projectName_auth"; } ]; initialScript = '' CREATE ROLE postgres SUPERUSER LOGIN PASSWORD 'postgres'; CREATE ROLE api LOGIN PASSWORD 'api'; CREATE ROLE auth LOGIN PASSWORD 'auth'; ''; settings = { wal_level = "logical"; }; }; }; scripts = { drizzle.exec = "npx lerna run --scope @projectName/drizzle \"$@\""; better-auth.exec = "npx lerna run --scope @projectName/better-auth \"$@\""; }; } On Linux with SELinux, until the PR [2] is merged, a workaround for Zed needs to be applied: # ~/.config/containers/containers.conf [containers] label = false After this you can work within a podman container, connect to adjacent compose services, and use nix and devenv. If a collaborator wants to skip containers they can just run devenv locally. Though I think devcontainers running devenv is actually the easier route provided that they are setup and working on your OS. And this all works pretty much out of the box without root on an immutable OS like Fedora Silverblue/Kinoite. --- [1](https://github.com/microsoft/vscode-remote-release/issues/11...) [2](https://github.com/zed-industries/zed/pull/58500) [3](https://github.com/flathub/dev.zed.Zed/pull/342#issuecomment...)
In Show HN: Nucleus – A security-hardened, Nix-native container runtime
amluto·May 20, 2026Recommendation phrase
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 workspace config explicitly uses some kind of sandbox.) So the workspace can usually trivially elevate permissions to take over the vscode server, including installing extensions on it without asking you. In principle, there is a teeny tiny bit of isolation between the local and remote sides, so the remote side cannot trivially execute code on the local machine. But I recommend reading this rather long-standing ticket: https://github.com/microsoft/vscode-remote-release/issues/66...
In GitHub confirms breach of 3,800 repos via malicious VSCode extension
"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 bananas
Not 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 bananas
VSCode’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
Read the rest
In VSCode’s SSH agent is bananas
I think that you and tredre3 are entirely missing the problem — you seem to be assuming that vscode works the way that any sensible person would assume that it works. Of course VS Code runs things remotely. Of course running an untrusted project on a remote machine runs code on the remote machine. This isn’t the problem. The problem is that the remote project can run code on the client front end. You can create a brand new cloud machine, give it no particular permissions, run vscode on your laptop, connect to the remote machine via the remote extension, and load some compromised package npm package, and you expect that the damage is limited to the remote machine. And you would be wrong! The npm package can execute code on your laptop or borrow your ssh credentials, and MS doesn’t even consider this to be a bug! https://github.com/micros
Read the rest
In VS Code extensions are less secure than browser extensions or even NPM packages
As a person who administers servers I absolutely HATE that vscode does this. I don't know much about the specifics of remote deployment, but I feel like having vscode do this is just the wrong approach. I would say it probably needs to be some other CI/CD pipeline or something outside of the editor. The problems I have is that every user gets like 1.5G of node junk stuffed in their home directory to support this. VScode spawns processes as the user that can't be controlled that can just kill servers (This is one bug I found, but there are issues with this that go much farther back than 2 years ago, https://github.com/microsoft/vscode-remote-release/issues/26...) There doesn't seem to be any way to control this on the server side, so if I have users with the ability to write to their home directory, I cannot stop them from pushing this a
Read the rest
nd potentially killing an instance.
In I’m switching from VS Code to VS Codium

Showing the 15 most recent of 26 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.