VS Code Remote Tunnels: Access Your Windows Dev PC Anywhere Without SSH or Port Forwarding

Below is what the feature does, how to turn it on, what Microsoft's documentation says about security and limits, and where the browser experience falls short.

What Remote Tunnels actually does​

Remote Tunnels is not remote desktop. Your desktop isn't streamed to you as video. The machine you want to reach (the "host") runs a VS Code Server, and your client device connects to it through Microsoft's dev tunnels service. The client can be a browser or another copy of VS Code.

Microsoft's documentation describes the Remote - Tunnels extension as a way to connect to a remote machine, like a desktop PC or virtual machine (VM), via a secure tunnel. You can connect to that machine from a VS Code client anywhere, without the requirement of SSH.

What that means in practice:

• Your code stays on the host. The extension runs commands and other extensions directly on the remote machine, so the source never has to sit on your laptop or tablet.
• The host does the heavy lifting. Terminal commands, builds, debugging and workspace-aware extensions all run on the desktop.
• The client is just the interface. Microsoft says you can still get IntelliSense, code navigation and debugging no matter where the code lives.

Singh says this is what makes it useful for him. He has traveled with only an iPad, kept his files on his PC, and still worked in his full desktop environment from a browser.

Section summary: Tunnels gives you a VS Code window that runs on your desktop's hardware. It is not a pixel stream of your screen.

Why the browser part matters​

Ordinary VS Code for the Web (vscode.dev) runs entirely inside the browser sandbox. Microsoft's own documentation says the terminal and debugger aren't available there, because you can't compile or run a native app inside a browser tab. It's meant for browsing repositories and making small edits.

A tunnel changes that. Microsoft's web documentation recommends Remote Tunnels when you need a runtime, a terminal, build and debug tools, or extensions that don't work on the web. The phrase it uses is "bring your own compute": the browser gives you the editor, and your desktop provides the processing power.

Singh says it plainly: VS Code on the web is good for light editing but can't run a project on your desktop until you connect it through a tunnel.

How to turn it on: two routes​

Microsoft documents two ways to start a tunnel. Both give you the same result.

Route 1: The VS Code desktop UI (the easy one)​

1. Open VS Code on the machine you want to reach remotely, such as your desktop.
2. Click the Accounts icon in the lower-left corner and choose Turn on Remote Tunnel Access. You can also press F1 and run Remote Tunnels: Turn on Remote Tunnel Access...
3. Sign in when asked. Microsoft's UI walkthrough shows a GitHub sign-in prompt at this step.
4. VS Code shows a notification with a vscode.dev link for that machine. That link is your way in.

Route 2: The code command line​

The CLI comes with VS Code Desktop, so nothing extra needs installing. In a terminal on the host, run:

code tunnel

This downloads and starts VS Code Server, creates the tunnel, and prints a URL in the form [Visual Studio Code for the Web](https://vscode.dev/tunnel/)<machine_name>/<folder_name>. The first time you run it, you'll be asked to accept the VS Code Server license terms. You can skip that prompt by adding --accept-server-license-terms.

Some useful extras from documentation and community guides:

• Give the machine a name. Arm's VS Code Tunnels install guide uses code tunnel --name my-tunnel-1 --accept-server-license-terms and notes that if --name is not used, an arbitrary name will be assigned to the tunnel.
• Headless or minimal machines. Microsoft offers a standalone CLI download for computers without the desktop app. With that version, commands start with ./code instead of code.
• Explicit login. One recent headless-setup guide uses code tunnel user login --provider github and says the CLI prints a device code and a GitHub login URL. Open the URL in a browser, enter the code, and approve the authorization.
• Everything else: code tunnel --help lists all the options.

Connecting from another device​

• From a browser: Open the vscode.dev link and sign in with the same account you used on the host. If you've lost the link, Arm's guide says you can open vscode.dev, click the lower-left corner, and choose Connect to Tunnel.
• From another copy of VS Code: Install the Remote - Tunnels extension, press F1, and run Remote Tunnels: Connect to Tunnel. Your machines also appear in the Remote Explorer view, and when you're connected, the green remote indicator in the lower-left corner shows the host's name.

What success looks like: a VS Code window, in a browser or on the desktop, where you can open folders on the host, edit files, and open a terminal that runs on the host.

Section summary: If VS Code is already open, use the Accounts menu. If the machine is headless or you want automation, use code tunnel. Either way, connect with the same account on both ends.

The catch: the host has to stay awake​

Singh's main caveat is that the computer has to stay on and VS Code has to keep running. Microsoft's documentation agrees for the UI route: the machine is reachable only while VS Code is running there, and once you quit VS Code the tunnel is gone until you restart it or run the CLI.

That's fine for a desktop PC or a Mac mini. It's less great for a laptop you'd have to leave plugged in and open all day. Microsoft documents two CLI options that help:

• Run it as a service: code tunnel service install sets the tunnel up as a background service, and code tunnel service uninstall removes it. A developer who wrote up an iPad-based setup on their blog said they went this way because starting the tunnel can be repetitive. I wanted my tunnel to run as a service and always available.
• Stop the machine from sleeping: code tunnel --no-sleep keeps the host awake.

A sensible check after installing the service: reboot the host, then confirm the tunnel shows up again in the Remote Explorer on another device. If it doesn't, the service didn't register properly.

Security: how much should you trust it?​

Is opening a remote coding door to your desktop a good idea? It depends on how you look after your accounts. Here's what Microsoft's tunnel documentation says:

• Authentication on both ends. Hosting a tunnel and connecting to it both require signing in with the same GitHub or Microsoft account.
• Outbound connections only. Both sides connect out to a service hosted in Azure. Microsoft says firewall changes generally aren't needed and VS Code doesn't open any network listeners. This is why you don't need to forward ports or run an SSH server.
• End-to-end encryption. Once a remote VS Code instance connects, an SSH connection is created inside the tunnel. Microsoft names AES-256 in CTR mode as the current preferred cipher and says the code that implements it is open source.

Our take, based on general industry practice rather than Microsoft's documents: the tunnel moves your attack surface from an open network port to your identity. Anyone who gets into the GitHub or Microsoft account linked to the tunnel gets a terminal on your desktop. Turn on multi-factor authentication for that account, and think twice before tunneling into a machine that holds sensitive client code.

For IT admins, Microsoft gives two controls. You can allow or block the domain global.rel.tunnels.api.visualstudio.com to control access to the tunneling service. On Windows devices, you can deploy Group Policy settings for dev tunnels. If you manage developer workstations and didn't know your users could do this, now you do.

Limits and rough edges​

• One user at a time. Microsoft says a server instance is built for one user or client at a time. This is not a pair-programming tool.
• Tunnel cap. Microsoft's documentation currently lists a limit of 10 registered tunnels per account. If you create an eleventh, the CLI deletes a random unused one. Microsoft says this limit may change.
• Browser support. VS Code for the Web supports the latest versions of Chrome, Edge, Firefox and Safari. Older versions aren't guaranteed. Webviews may behave oddly in Firefox and Safari.
• Keyboard shortcuts. Some shortcuts conflict with browser shortcuts. For example, Ctrl+Shift+P won't open the Command Palette in Firefox, so press F1 instead.
• Small screens. Microsoft says mobile use works but smaller screens have limitations. Singh's iPad workflow is real, but don't expect a tablet to feel like a 27-inch monitor.
• Extensions. Extensions that run on the remote host do their work there. Browser-only extensions still have to be compatible with the web sandbox.

Cleaning up​

• If you started the tunnel from the CLI, press Ctrl + C to stop it.
• If you started it from the UI, run Remote Tunnels: Turn off Remote Tunnel Access...
• To remove a machine completely, run code tunnel unregister on that machine, or right-click it in the Remote Explorer and choose unregister.

Tunnels vs. Remote SSH​

Singh has used Remote SSH a lot. He says it works well for servers he can already reach, but setting up a new machine means an SSH server, login credentials, a network route to it, and, from outside the house, some way into his home network. With Tunnels, he signed in once from the Accounts menu and could connect from anywhere.

That fits Microsoft's design. One thing to push back on: Singh's description of Remote SSH as "geared more toward enterprise environments" is his opinion, not something Microsoft says. Remote SSH is still the better choice when SSH is already set up, when company policy requires it, or when you don't want a third-party relay involved at all. Tunnels depends on Microsoft's dev tunnels service and on your GitHub or Microsoft account. SSH depends on infrastructure you control. Both are fine choices for different situations.

Tunnels also works with other remote tools. Microsoft says you can connect to WSL and dev containers over a tunnel. You can even open a folder on the tunnel host inside a container without Docker installed on your local machine.

Bottom line​

Singh admits he isn't uncritical of VS Code. He's tried Cursor, Zed and Antigravity, says VS Code isn't the fastest editor, and doesn't like Microsoft's telemetry. He keeps coming back for reliability, and Remote Tunnels is a good example of why.

If you develop on a Windows desktop and sometimes work from a lighter laptop, a Chromebook or an iPad, try it. Start with the Accounts menu, install the service if you want the tunnel always available, and secure your sign-in account properly, since it's now what stands between the internet and your terminal.