microsoft/vscode-remote-release: what the feedback repo is, and how to run VS Code over SSH, Tunnels, Dev Containers or WSL

What microsoft/vscode-remote-release actually is

The name suggests a source repository. It is not one. The README states plainly that the repository exists "for providing feedback on the Visual Studio Remote Development extension pack and its related extensions", and it lists exactly which extensions fall under that umbrella: Remote - SSH (plus Remote - SSH: Editing Configuration Files), Dev Containers, WSL, and Remote - Tunnels together with the Visual Studio Code Server. If you clone it expecting the code that opens a folder over SSH, you will find documentation, issue templates, security and support files, and three NOTICE files (NOTICE-remote-containers.txt, NOTICE-remote-ssh.txt, NOTICE-remote-wsl.txt). The primary language on the repository is Dockerfile, which is a fair signal of how much application code lives here.

The audience is therefore narrower than the topic list suggests. It is for people who have already installed the extensions and hit a wall: a connection that will not complete, a container that will not build, a WSL distro that VS Code cannot see. It is also the place to up-vote features and to find the pinned planning issue for the current development iteration. It is not the place to learn how Remote - SSH works internally, and it is not a distribution channel: the README sends you to aka.ms links for downloads rather than to release assets in this repository.

How the four extensions split the work

The extension pack covers four connection models, and the differences matter when you choose one. Remote - SSH connects to a machine you can already reach over SSH and runs the VS Code server there, so your terminal, debugger and language servers execute on the remote host while the UI stays local. WSL does the same thing for a Linux distribution running under Windows, but without an SSH hop: VS Code talks to the distro directly. Dev Containers goes a step further and treats a container as the development environment, which is why the README points container-related issues at the devcontainers organisation, where Features, Templates and Images each have their own repository and the open source dev container CLI lives at devcontainers/cli.

Remote - Tunnels is the odd one out. Instead of you reaching the machine, the machine registers a tunnel and you connect to it from a VS Code client. That is the mechanism behind the Visual Studio Code Server, and it is the reason a browser or a phone can act as the client. The README links the extension on the marketplace and the server documentation separately, which is a hint that the two are documented as a pair rather than as a single feature. If your question is which of these to pick, the deciding factor is whether the code already lives somewhere you can reach over the network (SSH), somewhere on your own Windows machine (WSL), somewhere you want to reproduce exactly (container), or somewhere behind NAT that should dial out to you (Tunnels).

Installing the extension pack and opening a remote folder

There is no build step in this repository. Installation happens through the marketplace, and the README gives a single entry point for the whole pack at aka.ms/vscode-remote/download/extension, with per-extension links for Remote - SSH, Dev Containers, WSL and Remote - Tunnels. In VS Code itself the usual route is the Extensions view, where the pack appears as "Remote Development".

The README also mentions VSIX files indirectly through the download links, and the related searches show people look for a VSIX specifically. The repository does not publish release assets, so the VSIX for each extension comes from its marketplace page, not from a GitHub release here. Once the pack is installed, the first real use is opening a folder that is not on your local disk. From the Command Palette:

# In VS Code: Ctrl+Shift+P (Cmd+Shift+P on macOS), then run:
# Remote-SSH: Connect to Host...
# Dev Containers: Open Folder in Container...
# WSL: Open Folder in Linux Distribution
# Remote - Tunnels: Connect to Tunnel...

What you should see depends on the model. For SSH, VS Code prompts for a host from your SSH config, then installs the VS Code server on the remote machine and reopens the window with the remote indicator in the lower-left corner. For containers and WSL, the window reopens against the container or distro instead. The remote indicator is the thing to watch: when it is present, extensions, terminals and tasks run on the remote side, and when it disappears you are back on your local machine.

Where the repository is the wrong tool

The README draws the boundary itself, and it is worth taking at face value. If your problem is with another extension that you happen to use alongside the Remote Development pack, the README tells you to raise the issue in that extension's repository, pointing authors at the extension guide and at the summary of remote-related tips. Filing it here will not reach the maintainer who can fix it. The same applies to the Dev Container ecosystem: Features, Templates and Images belong to their own repositories, and CLI issues belong to devcontainers/cli. The dev container spec repository is where you file issues that shape the direction of the spec and the CLI.

The second limitation is structural. Because this is a feedback repository, there is no code path to inspect when something behaves unexpectedly. You cannot read the connection logic, you cannot bisect a regression, and the README does not document rollback or downgrade procedures for the extensions. Stable releases are tied to VS Code releases, so pinning an older extension version is not a workflow the README describes. If your team needs to audit exactly what runs on a remote host, this repository will not answer that; the NOTICE files and the product licence terms linked from the README are the closest you get.

How it compares with a browser-based remote IDE

The obvious alternative for editing code on a remote machine is a browser IDE such as a self-hosted web editor, and the difference in approach is architectural rather than cosmetic. A browser IDE runs the whole editor on the server and streams a web UI to whatever client you have. VS Code Remote Development keeps the editor UI local and installs only a server component remotely, so the client is a desktop application with local keybindings, local extensions that do not need the remote environment, and local rendering.

Remote - Tunnels blurs that line, and the README treats it as its own extension rather than a variant of Remote - SSH. With a tunnel, the machine you want to reach dials out, and you connect from a VS Code client, including the Visual Studio Code Server. That is the same reachability problem a browser IDE solves, solved by reusing the VS Code client. The trade-off is that you are still running a desktop client, so a phone or a locked-down machine without VS Code installed is not a target unless you use the server. If you want a browser tab and nothing else, Remote - Tunnels plus the VS Code Server is the path this repository documents; if you want a native client and a host you can already SSH into, Remote - SSH is the smaller moving part.

Maintenance, release cadence and licence terms

The last push to this repository was on 2026-09-04, and the repository is not archived, so the issue tracker is live. That is a statement about the tracker, not about the extensions. The README says stable releases are tied directly to VS Code releases, that release highlights appear in the VS Code release notes with a link to detailed extension release notes in microsoft/vscode-docs, and that the extensions follow the same development process and iteration schedule as VS Code itself. During an iteration, changes may only be available in VS Code Insiders. Practically, that means your upgrade cost is coupled to your VS Code upgrade cost: you do not version the remote extensions independently, and the README does not describe a channel for holding them back.

The licence situation is split and worth reading carefully before you redistribute anything. The repository content is under Creative Commons Attribution 4.0 International, per the header and the licence section. The extensions are not: the README states that by downloading and using the extension pack you agree to separate product licence terms and a privacy statement, both linked from the README, and the repository carries LICENSE-extensions alongside LICENSE-repository. The repository metadata reports the licence as NOASSERTION, which reflects that split rather than a single declared licence. This is a description of what the files say, not legal advice; if you plan to bundle the extensions into an internal distribution, read the product licence terms yourself.

Editorial conclusion

Adopt the Remote Development extensions if you already live in VS Code and need to edit code that sits in WSL, a container or on another machine; install them from the marketplace links in the README rather than expecting this repository to ship binaries. Do not treat microsoft/vscode-remote-release as an extension source tree: it holds issue templates, docs and licence notices, and the README points extension bugs to the extension's own repository and Dev Container ecosystem bugs to devcontainers/cli, devcontainers/features, devcontainers/templates or devcontainers/images. Before filing anything, check the pinned planning issue to see whether your problem is already scheduled for the current iteration, and read the troubleshooting page linked from the README. The last push was on 2026-09-04, so the tracker is moving, but that says nothing about the release cadence of the extensions themselves.

Frequently asked questions

Official sources

1. Issues
2. microsoft/vscode-remote-release on GitHub
3. Project website
4. README