Open Remote SSH puts the editor backend on the machine you are working on

The extension runs the editor on the remote machine

The project description is VSCode Remote Development: open any folder on a remote machine using SSH, and the package manifest puts it more plainly, use any remote machine with a SSH server as your development environment. The point of the arrangement is that the editing session is not a local editor pointed at a mounted path. The editor backend is installed on the remote machine, the files you open are the files that live there, and the tools you run, the language server, the terminal and the build, are the ones on that machine. That is the difference from the obvious alternative of editing locally and copying files, and it is the reason an extension of this kind needs a remote server component, a version negotiation mechanism and a set of platform specific download URLs. The package manifest shows the shape of a standard VS Code extension, with a main and browser entry point at ./lib/extension.js and an engines requirement of vscode ^1.70.2.

The remote side is a real SSH server with a forwarding requirement

The requirements section is where the deployment reality shows. You can connect to a running SSH server on the supported platforms, and the list is specific: x86_64 Debian 8+, Ubuntu 16.04+, CentOS and RHEL 7+; ARMv7l on Raspbian Stretch or 9+ in 32-bit; ARMv8l on Ubuntu 18.04+ in 64-bit; IBM Z on Debian 13, RHEL 8+, Ubuntu 22.04+ or SLES 15+; macOS 10.14 Mojave and later; Windows 10 and later; FreeBSD 13+, which requires a custom serverDownloadUrlTemplate setting; and DragonFlyBSD, which requires a manual remote-extension-host installation. There is one configuration requirement on the server, and it is the setting that matters: your SSH server's configuration needs AllowTcpForwarding yes. The channel the extension uses to reach the remote editor is a forwarded TCP connection, so a server that disables forwarding will not work no matter what the client does.

Activation needs an entry in argv.json

The extension uses a proposed API, so it has to be listed in the runtime arguments file. The README calls this the activation step and gives the shape of the file:

{
    ...
    "enable-proposed-api": [
        ...,
        "jeanp413.open-remote-ssh",
    ]
    ...
}

The file is opened with the Preferences: Configure Runtime Arguments command and lives at ~/.vscode-oss/argv.json. There is one exception worth remembering, and it is stated as a note: the step is not needed in VSCodium since version 1.75, because that build allows the proposed API without the explicit opt in. So on current VSCodium you can install the extension and connect, and on the older builds, or on VSCode-OSS, you are editing a runtime configuration file by hand before the extension will load.

The OSS build needs four settings changed

If you are on VSCode-OSS rather than VSCodium, the README says you need some extra steps, and it names the four plugin settings to modify:

"remote.SSH.serverBinaryName": "codium-server",
"remote.SSH.serverDownloadUrlTemplate": "https://github.com/VSCodium/vscodium/releases/download/${version}${release}/vscodium-reh-${os}-${arch}-${version}${release}.tar.gz",
"remote.SSH.serverVersion": "latest",
"remote.SSH.serverValidation": "force",

The reason is a naming difference between the two distributions. VSCodium versions have an extra release part that has no equivalent in VSCode-OSS, so leaving serverVersion at the default of match will fail. Setting serverVersion to latest installs the latest release of VSCodium, and setting it to closest fetches the last release of VSCodium for the version you are running. The README also explains that the local and remote versions usually do not match on VSCode-OSS, so the validation has to be bypassed, and that serverValidation set to force modifies the commit of the remote server to match the local one, while skip makes the remote server skip the check, an option that works only if the remote VSCodium version is 1.120 or newer. There is a second wrinkle with the download URL scheme, because starting with VSCodium 1.99.0 the release number is no longer separated from the version by a dot, so before 1.99.0 the older template has to be used:

"remote.SSH.serverDownloadUrlTemplate": "https://github.com/VSCodium/vscodium/releases/download/${version}.${release}/vscodium-reh-${os}-${arch}-${version}.${release}.tar.gz",

SSH config files, jump hosts and Kerberos

Connections can come from your own SSH configuration rather than from entries typed into the extension. The README notes that OpenSSH supports using a configuration file to store all your different SSH connections, and to use one you run the Remote-SSH: Open SSH Configuration File... command. That means host aliases, ProxyJump entries and identity files all come from the same file the ssh command already reads, which removes a second place to maintain. Two configuration guides are linked for cases the extension cannot solve by itself. One covers GSSAPI and Kerberos authentication, and the other covers jump hosts, for the common case of reaching a machine through a bastion. Both are documents in the repository's docs directory rather than features in the code, which is a reasonable division for the kind of setup that is mostly ssh_config and Kerberos configuration.

The extension toolchain is a modern Node and TypeScript setup

The package manifest shows how the project is built and tested. The build chain is a clean script, then tsc -b for the TypeScript sources, then webpack in production mode, with a separate development bundle and a watch mode built on tsc-watch. Tests run on vitest with the tree reporter, with coverage and a UI mode, and there is a dedicated script for image tests that shells out to bash ./dockerfiles/build.sh, which is how the extension is exercised against real remote images rather than mocks. Linting is split into four passes, with eslint, a package check through fixpack, an npm audit step, and a zizmor pass that covers GitHub Actions security. Releases go through release-it with a .release-it.yml configuration, commits are checked with commitlint, and husky manages the git hooks. The tree also carries a .nsprc policy file, an .artifactrc.yml for build artifacts, a .tazerc.json for a task runner, and a dockerfiles directory, so the remote images themselves are versioned here.

The manifest version and the release tags are not the same number

One detail to check before you pin anything. The package manifest declares version 0.4.0, while the release tags are the 0.4.1 beta series, with v0.4.1-beta.3 on 2026-10-15, v0.4.1-beta.4 on 2026-10-17 and v0.4.1-beta.5 on 2026-10-18. The repository is not archived and the last push was on 2026-10-19, so the work is current, and the version in the manifest is simply not bumped for every beta tag. The consequence for an installer is that the beta numbering is what you will see in the marketplace and in the tag list, while the manifest number is what the extension declares about itself, so read the tag rather than the manifest when you are pinning a version. The licence is MIT, with LICENSE.txt at the repository root, and the project carries a CHANGELOG.md, a CONTRIBUTING.md and a CODE_OF_CONDUCT.md.

Editorial conclusion

Adopt Open Remote - SSH if you work on VSCodium or VSCode-OSS and need to edit code that lives on a remote machine, because it is built for those builds and documents the settings they need. Do not adopt it if you are on the Microsoft build of VS Code and want the upstream Remote Development support, or if the remote host is something outside the documented platform list. Before you install, check that the remote SSH server allows TCP forwarding, add the proposed API entry to argv.json, and read the server version rules for your build, since a mismatch between the local and remote commit is what stops the connection from validating.

Frequently asked questions

Official sources

1. Issues
2. jeanp413/open-remote-ssh on GitHub
3. License: MIT
4. README
5. Releases