VS Code online and networked

January 25, 2018 — April 5, 2024

computers are awful together
faster pussycat
plain text
Figure 1

Here be tips for using VS Code as a collaborative cloud-friendly editor, in several senses.

1 “Remote”

Remote edits code in particular environments from a local VS Code instance - including spinning up containers or SSH sessions, so that your editor and execution environments can be different. The remote execution environments can be elsewhere on the internet, or they can be local VMs, which is why I have “scare quotes” around the word “remote”. VS Code tries hard to make this rather different configuration seamless, installing some helper files on the remote side that interact smoothly with the local side and smushing the two together. Occasionally some extensions will not work gracefully across the barrier between local and remote, but for most of my workflows the problem does not arise. This is generally the easiest option for remote jupyter usage, and I use it all the time.

Figure 2

Use in practice is best explained by using the tutorial examples.

Tutorial Description
Remote via SSH Connect to remote and virtual machines with Visual Studio Code via SSH.
Work in WSL Run Visual Studio Code in Windows Subsystem for Linux.
Develop in Containers Run Visual Studio Code in a Docker Container.
GitHub Codespaces Connect to a codespace with Visual Studio Code.

Also I wrote one about getting remote debugging for python working in a fiddly environment, see below.

Pro tip: remote editing via unreliable or intermittent network connection can be a drag. There is no universal persistent SSH session solution at time of writing. It would be nice if it worked over eternal terminal but it does not. However, Christopher LaPointe’s solution using tmux provides a bandaid solution.

Microsoft’s Dev tunnels does not appear to be an SSH tool, but its tunnels look similar, except with certain advantages such as * Persistent SSH sessions over unreliable connections.

Points of friction: Jupyter Notebook can interact badly with VS code remote, losing data if there is a buggy extension installed. (See also.)


  "terminal.integrated.profiles.linux": {
    "tmux": {
      "path": "/usr/bin/tmux",
      "args": [
  "terminal.integrated.defaultProfile.linux": "tmux",
  "remote.SSH.defaultForwardedPorts": [
      "localPort": 9002,
      "remotePort": 9002,
      "name": "SA"

A newish extension Remote Tunnels somehow obviates the need for SSH. I do not yet understand the value proposition of it.

I get the error “Failed to parse remote port from server”

Me too. It seems to be something to do with stale lock files:

rm .vscode-server/bin/**/vscode-remote-lock.*
Apparently my home folder is now full

If things crash, or if we switch from vs code to vs code insiders build, it can leave stake crap around.

I’m pretty sure that the ones that end in .bak or .locked are pointless.

rm -r .vscode-server-insiders* # or
rm -r .vscode-server*

2 VS Code server

Run a server process that makes VS Code accessible to you in a browser. No local copy of VS Code is required; you use a browser window for everything.

I have not had need of this yet, because any scenario where I have HTTPS browser access to a remote server, I have also had SSH access and so it has been easier to use the VS Code Remote setup.

However, a completely browser-based IDE might be useful in some circumstances: in exotic devops scenarios, through painful firewalls, when working from a thin client, something like that?

There are at several supported configs

Mainline VS Code server:

There are also two community-maintained forks:

I do not know the difference between the affordances of all these options.

3 Google Cloud

We can use VS Code as a remote APU for google cloud, apparently. Maybe. GoogleCloudPlatform/cloud-code-vscode: Cloud Code for Visual Studio Code: Issues, Documentation and more

Cloud Code for VS Code brings the power and convenience of IDEs to cloud-native Kubernetes and Cloud Run application development. Cloud Code works with Google’s command-line container tools like skaffold and kubectl under the hood, providing local, continuous feedback on your project as you build, edit, and run your applications locally or in the cloud.

4 Google Colab

Distinct, both in billing and API, from generic google cloud, but also possible?

5 Collaborative editing

A different type of networking: Not using my IDE to access remote files, but using my local IDE to share the editing experience with others. Many users can access the same VS code session at the same time and collaborate on the same code edits (not just, say, the same files). There is a real-time collaboration extension called liveshare

Welcome to Visual Studio Live Share! Live Share enables you to collaboratively edit and debug with others in real time, regardless of the programming languages you’re using or app types you’re building. You can instantly and securely share your current project, start a joint debugging session, share terminal instances, forward localhost web apps, have voice calls, and more!

Unlike traditional pair programming, Visual Studio Live Share allows developers to work together, while retaining their personal editor preferences (e.g. theme, keybindings), as well as having their own cursor. This allows you to seamlessly transition between following one another, and being able to explore ideas/tasks on your own. This ability to work together and independently provides a collaboration experience that feels much like in-person collaboration.

Live Share is built using revolutionary architecture and concepts that manifest as powerful features for our users. To learn about those features, see Live Share features.

TIP: Did you know that you can now join a Live Share session from the browser? This means, you no longer need to install a desktop client to collaborate! Just click on the link shared with you and you can get a full-fidelity VS Code editor experience in the browser. Learn more here.

6 Remote python debugger

Having said that everything is seamless, there are in fact edge cases where there divide between what is here on the client and what is there on the remote server, becomes important. One of those cases is interactive debugging.

Here is a worked example of what I needed to do to get a remote python debugger working from my local machine. Finding out why code that works locally does not work in the actual target deploy environment.

First need to install the debugpy package in our project. How to install depends how we are managing your python environment, but it will probably be one of these:

pip install debugy    ## 👈🏻 this one for me
conda install debugpy
poetry add debugpy

Now I choose a network port for the debugger.1 This port needs to be unique to me (in the sense that no-one else on the remote machine should be using it) and it should be between 1024 and 65535. For simplicity’s sake I will assume the port is 48888, but I would recommend against that number for you because someone else might have copy-pasted these instructions and got there first, if you are using a shared machine. (Although not me; I use different port numbers in reality, this is just a tutorial example).

Next, we do a one-time setup of VS Code to know that it should look for that port by finding the debug tab in VS Code and adding a configuration.

Figure 3:

This will open launch.json into which we can add a configuration for a remote attach debugger:

  "name": "Attach",
  "type": "python",
  "request": "attach",
  "connect": {
    "host": "",
    "port": 48888
  "pathMappings": [
     "localRoot": "${workspaceFolder}",
     "remoteRoot": "."

This part is clunky, but after one-time setup everything goes smoothly. VS Code will do all the remaining necessary networking by magic.

So NOW WE ARE READY TO DEBUG. Almost. We still need to load up our code on the server to USE the debugpy module. Two options here.

Firstly, we could invoke the code from the vs code terminal like this:

python -m debugpy --listen ./myscript.py

Alternatively, we could load and execute the debugging system inside myscript.py:

import debugpy
debugpy.listen(('', debug))

Either way, VS code will detect what I am doing and magically open up an SSH tunnel from here to there. Now, if you did the wait_for_client thing, the code will pause and wait for a debugger connection.

OK great, so now I select that debug configuration I created earlier in order to get my debugger to connect

Figure 4

I was stuck for ages on this. but now I ALSO NEED TO CLICK THE GREEN TRIANGLE or it doesn’t start. And then… That’s it. we are done.

The debugger will show what is happening in general, but it is especially useful when

  1. we hit a line that raises an exception, or
  2. the code hits the line breakpoint() which will cause the debugger to drop into the code right there.

How does the debugger work? I do not need to explain because microsoft has already done that. But tl;dr there is now a lot of information about my running code, a graph of the current call stack, a little tab to inspect the current value of variables etc.

7 Firewall rules we need

Pro tip. for use behind a firewall, AFAICT VS Code requires the following whitelist exceptions:

Liveshare requires

  • *.online.visualstudio.com
  • *.liveshare.vsengsaas.visualstudio.com:443

For github copilot:

  • vscode-auth.github.com
  • api.github.com
  • copilot-proxy.githubusercontent.com

A list of miscellaneous URLS that the VSCode likes includes

  • update.code.visualstudio.com - Visual Studio Code download and update server
  • code.visualstudio.com - Visual Studio Code documentation
  • go.microsoft.com - Microsoft link forwarding service
  • vscode.blob.core.windows.net - Visual Studio Code blob storage, used for remote server
  • marketplace.visualstudio.com - Visual Studio Marketplace
  • *.gallery.vsassets.io - Visual Studio Marketplace
  • *.gallerycdn.vsassets.io - Visual Studio Marketplace
  • rink.hockeyapp.net - Crash reporting service
  • bingsettingssearch.trafficmanager.net - In-product settings search
  • vscode.search.windows.net - In-product settings search
  • raw.githubusercontent.com - GitHub repository raw file access
  • vsmarketplacebadges.dev - Visual Studio Marketplace badge service
  • az764295.vo.msecnd.net - Visual Studio Code download CDN
  • download.visualstudio.microsoft.com - Visual Studio download server, provides dependencies for some VS Code extensions (C++, C#)
  • vscode-sync.trafficmanager.net - Visual Studio Code Settings Sync service
  • vscode-sync-insiders.trafficmanager.net - Visual Studio Code Settings Sync service (Insiders)
  • vscode.dev - Used when logging in with GitHub or Microsoft for an extension or Settings Sync
  • default.exp-tas.com - Visual Studio Code Experiment Service, used to provide experimental user experiences

In addition it will be easier to install extensions with the following exceptions

  • marketplace.visualstudio.com
  • vscode.blob.core.windows.net
  • *.vo.msecnd.net
  • *.gallerycdn.vsassets.io
  • download.microsoft.com (only some extensions)
  • download.visualstudio.microsoft.com (only some extensions)


  1. Technically we need to choose a port on the local AND remote machine, and these can be different, but why do that?↩︎