Hello dear reader, let me first introduce the problem. My setup is basically described as in the following figure:

A notebook, second HDMI screen and another desktop, which I'll call from now on "server" (it's a backup and spare my main machine from some heavy tasks). In my day to day, I mainly use the notebook and I don't need to interact much with the server, which by the way doesn't have a graphical interface and I don't connect to any screen:

Now, when I'm in "live", streaming to YouTube, my main machine gets a lot of workload, screen record, multiple cameras, overlays, compositing and streaming. As usually in my lives we need processing power to compile Linux Kernel, NuttX and other little things, I delegate this function to the server. Hence, I need a lot of interaction with the server, the server is now my main machine and the notebook is just for streaming media tasks:

Ok, but what's the problem? I'm used to WSL with Windows Terminal and VS Code. So my workflow is as follows:

We know that when we run code . in WSL, what really happens is a new remote connection with VS Code on the Windows side, but we don't even feel that because the integration is very transparent and it happens automatically.

The problem is that when I connect to the server, the flow is no longer transparent:

The best would be to just stick with the VS Code terminal, but I'm very used to Windows Terminal, for muscle memory I always open the remote connection first, via SSH, in the Windows Terminal shell. Aside from that VS Code terminal shell looks "strange" to me, I feel more "at home" using Windows Terminal for shell tasks. However, the code . integration only works, for this "non-WSL" remote connection case, inside the VS Code terminal.

Buuuut, if for WSL VS Code also behaves like a remote connection, and I can get the code . integrated and opening new instances of VS Code, there must be a way to integrate this for any other remote connection too 🤔.

And this is where our adventure begins. 😐.

On the server side the only dependency needed, in terms of software packages, is wget or curl, whichever you prefer. Besides, logical, the ssh server running for the remote connection.

Before configuring server-side integration, connect remotely using VS Code:

⚠️ It's important to leave this instance open, it will keep a socket connected between Windows and the remote machine.

Still on the server side, add the following line to your .bashrc :

export PATH=$PATH:/home/demo/.vscode-server/bin/$(ls -rt /home/demo/.vscode-server/bin/ | head -1)/bin

⚠️ Modify the demo by your user.

During the first remote connection, VS Code automatically downloads the resources needed to run vscode-server. These resources will be installed in the folder of the user you connected to /home/<user>/.vscode-server. And we need to add this path to our PATH environment variable, so we have access to the code command.

If at this point with the PATH already configured, we type code .:

Ahh VS Code, we will not give up that easy. What does VS Code have that my shell doesn't 🤔?

And here's the secret. For the remote connection VS Code opens a socket and shares it inside the remote machine. But the code command of the .vscode-server needs a reference to that socket. So, also add this line to your .bashrc:

export VSCODE_IPC_HOOK_CLI=$(ls -rt /tmp/vscode-ipc-* | head -1)

⚠️ Depending on your Linux distribution and configuration, the sockets path may change. The tip is, during the first connection using Remote Explorer in VS Code open a new terminal and check the environment variable VSCODE_IPC_HOOK_CLI.

This is the environment variable that VS Code expects to have with the reference to connect.

Now, when typing code . we will see a new instance of VS Code being opened and automatically connecting to the remote folder:

In the end, .bashrc will have these two lines:

export VSCODE_IPC_HOOK_CLI=$(ls -rt /tmp/vscode-ipc-* | head -1)
export PATH=$PATH:/home/demo/.vscode-server/bin/$(ls -rt /home/demo/.vscode-server/bin/ | head -1)/bin

⚠️ Modify the demo by your user.

⚠️ Depending on your Linux distribution and configuration, the sockets path may change. The tip is, during the first connection using Remote Explorer in VS Code open a new terminal and check the environment variable VSCODE_IPC_HOOK_CLI.

Using this integration and setting the VSCODE_IPC_HOOK_CLI environment variable I get a very similar workflow to what I'm used to with Windows Terminal shell as the main shell: