Vs-Code on blog.iankulin.com

VS Code Dev Containers

Sat, 10 Jan 2026 00:00:00 +0000

Remote-SSH

One of the things I’ve done a bit in Visual Studio Code is using it’s ability to work on a different machine over SSH. I have a couple of LXCs on a server set up for different languages - one for C++ and another for Rust. They are things I don’t work in often, and I didn’t want to set them up on my laptop, but thought I might want them again sometime in the future.

This is straightforward in VS Code - You install the remote ssh extension locally, then choose Remote-SSH: Connect to Host in the command palette. A few seconds later, it appears that you’re working locally, but actually you are working in a remote session on the server your VS Code instance is SSH’d into (a small indicator in the bottom left is the tell). You need to clone your project from git since you’re working in the server’s file system, and there’s some complexity with extensions since you’re sort of working in a new VS Code instance, but apart from that it feels the same as working locally.

The official docs for Remote Development using SSH are here.

Why now?

The reason I’ve been interested in this again lately is to provide a more secure environment for using AI agentic coding tools like Claude Code. If it’s running in it’s own server (that I can easily recreate from a snapshot) I don’t have to worry about dramas like having my hard drive deleted by Gemini.

But what if you don’t have the ability to spin up an environment on your homelab? There’s a few options, but probably the easiest for VS Code users is to work in a ‘Dev Container’.

Dev Containers

Working in a Dev Container is basically the same as remoting into another server with VS Code, but in this case the other server is a container spun up in Docker.

There’s a couple of important differences from working on a remote server:

we’re working on our local files;
Dev containers are an important system for sharing repeatable development environments, so it’s well integrated into VS Code - the tooling is nice.
You need Docker/Docker desktop running locally.
You need a container image to work with, and a devcontainer.json file to tell VS Code how to manage all this.

The rest of this post will focus on the basics of working in a Dev Container. There is also a good explanation of all this in the VS Code docs.

The Container

After you’ve installed the VS Code extension, and set up your local Docker environment, you’re going to need a Docker container to work in. There’s a big list of existing containers that cover most scenarios, but I prefer to roll my own. This is achieved by writing a Dockerfile.

FROM node:24-bookworm

# Use non-root user for development
USER node

# Development environment
ENV NODE_ENV=development

# Default command
CMD ["npm", "start"]

I’m going to name this Dockerfile.dev and put it in the .devcontainer directory - later we’ll point to it from our devcontainer.json

The Dockerfile describes the system that we’ll be working in when we’re working on our project - it’s like the specification of our remote ‘server’. Sometimes you might want to install other stuff here - for example if you are a vim enthusiast, you might apt install vim in the Dockerfile, but generally you should keep it reasonably generic.

devcontainer.json

Next we need to tell VS Code how to work in the container we’ve specified.

{
 "name": "Node.js Dev Container",
 "build": {
 "dockerfile": "Dockerfile.dev"
 },
 "forwardPorts": [
 3000
 ],
 "postCreateCommand": "npm install"
}

This goes in the .devcontainer directory. It’s almost all self explanatory - we tell the extension what container we’re using - in this case building it from Dockerfile.dev, export the port we’re running on, and run a command in the terminal of our new system once it exists.

What’s missing?

Alert readers will have noticed there’s a couple of things that we need which are missing.

VS Code Server - the way that VS Code is working in this configuration is that it’s running on our local machine, but connecting to a “VS Code Server” inside the container.
Bind mounts to our local directory - Once we load up the dev container, all our local files will need to be available in VS Code somehow.

So how to these get in the container? We don’t have to do anything to deal with these two issues. This is part of the magic that the VS Code Dev Container extension is doing for us. After the container is created, the extension:

installs the server binary, and starts it
bind mounts the local workspace to /workspaces/<your-folder-name>
And sets that as the WORKDIR in the container

Let’s go

Okay, with the Dockerfile.dev and devcontainer.json in place, we’re now ready to launch our devcontainer.

In the VSCode command pallet, run Dev Containers: Reopen in container. The first run will take a few moments since the container has to be built first, but then it should look something like this:

The big clue that you’re in the dev container now is the blue message in the bottom left corner. Most everything that we could do in the local environment we can do here in the container - for example editing code and running it.

Extensions

If you have a look at your VS Code extensions while working in this dev container, you’ll see that some are still installed, but others are now greyed out. Some extensions only effect the UI (“UI Extensions” - listed under “Local - Installed”) so they live in the local VS Code, others have functionality that needs to run in the workspace environment so they (“Workspace extensions”) need to live in the VS Code server part.

Any UI Extensions you had installed before will still be there since they live in the local VS Code, but they others will be greyed out and unavailable unless you install them into the dev container.

In the image here you can see my “vscode-icons” and “vscode-pdf” which only effect how things are displayed are both still available, but “Beancount” & “Cline” that need access to files need to be installed in the container if I want to use them on this project.

We can click on the “Install in Dev Container” button for any of these, and it will be installed into the dev container. I need ESLint for this project so I’ll could that - then it will appear in the ‘Dev Container’ tab. This is a good way of mimicking the normal workflow for users, but this extension is only persisted in the container while it exists - If we make any changes to the dockerfile or devcontainer.json VS Code will rebuild the container and the extension will be gone again.

If we want a workspace extension, a more persistent way to install it is to add it to our devcontainer.json

Adding extensions to devcontainer.json

Extensions added this way will be the same for anyone who uses our dev container definition (which is what I’m calling the combined dockerfile and devcontainer.json), including if they just clone the project from git. In fact, this was the original intention of dev containers - to have a fully reproducible development environment that is stored with its project.

Let’s add a couple of extensions.

{
 "name": "Node.js Dev Container",
 "build": {
 "dockerfile": "Dockerfile.dev"
 },
 "customizations": {
 "vscode": {
 "extensions": [
 "dbaeumer.vscode-eslint",
 "esbenp.prettier-vscode"
 ]
 }
 },
 "forwardPorts": [
 3000
 ],
 "postCreateCommand": "npm install"
}

If you make these changes in VS Code, it will probably pop up and ask you if it can rebuild the container, otherwise open the command palette and select “Dev Containers: Rebuild Container”.

You might be wondering where we get the extension id’s from (like dbaeumer.vscode-eslint) The easiest way to to right click on one in the extension list and select “Copy Extension ID”. It’s also listed on the extension web page.

Finally

So that’s the basics of getting a simple dev container set up. The code for this is on GitHub here. There’s a crucial issue we haven’t solved though - how to pull in your ssh keys for pushing the code to external repositories. We’ll deal with that in a future post.

Use VS Code to work on remote files

Thu, 21 Sep 2023 00:00:00 +0000

If you’ve got a script, or some code to work on, and it’s on a VM somewhere, you can always ssh in and use nano or vim to make your edits. Like a caveman. With an archaic editor, no intellisense, and no spell checking.

Or….

This magic - of editing a files on a remote server over SSH is achieved by using a Microsoft plugin for VS Code - “Remote - SSH”

How the plugin works is that it installs a copy of VS Code Server on the remote machine, then connects to it over SSH.

The experience is pretty great, once it’s installed (which I’ll run through below) it’s as if you are natively on the remote machine - the terminal is in the current directory on the remote machine, you can navigate around your files, edit them, use git, drag local files in and drop them in your remote folder and run your code.

Setup

You need to be able to SSH into the remote machine, preferably with keys if you want a smooth experience. I’ve talked about this before if that’s new to you.
Install the Remote-SSH plugin

Once that’s done, there will be a “Remote Explorer” icon over on the left edge of the VS Code window. If you click on that, the explorer area will show a list of machines you’ve configured. There’s a + to add a new one.
If you click on that, it will ask you to enter the SSH command to access a machine.

When you hit enter on that, it will ask you where to save the config file - I just chose the top one since that’s where I usually go to edit known_hosts etc.

You can get back to this config file later by clicking on the gear icon next to SSH in the remote explorer. That’s what I’ve done in the screenshot below to change the server name to something a bit more memorable.

With that all set up, just click on the “Connect in New Window” icon next to the server you want to work on.

Once the connection is established, new VS Code window will open up, with the files in the remote directory loaded ready for work. The status of the connection is shown in the bottom left corner of the window.

If anything here didn’t make sense, there’s a good tutorial on the Visual Studio Code website, or if you’re more of a video person, this overenthusiastic guy has a good quick summary.

Hide 'Problems' for a file in VS Code

Fri, 25 Aug 2023 00:00:00 +0000

I’m interested in trying out Pico CSS - a lightweight CSS library, but when I tossed it into my project, the linter found and reported 29 problems. One of my processes is to just keep that problems tab clear as I work, so I’d like that to go away.

It’s possible, but only by ’excluding’ the file from your project - it won’t show up in the file view either. That’s fine with me, I never want to deal with the file so we’ll do that, although it might confuse me in seven years if I come back to this project, so I’ll drop a link in my .git_ignore as a clue for future me (excluding the file in VS Code doesn’t affect git finding it).

Workspace settings (such as excluding a file) are stored in ./vscode/settings.json - this has some other bits and pieces such as spelling corrections etc. It’s worth letting this into your repository so your workspace is recreated when you clone the repo. The fragment you need to add is:

 "files.exclude": {
 "**/pico.min.css": true
 }

This will remove it from the files, and it will stop it being processed by your extensions including any linters. If the problems don’t disappear instantly, click into a different file for a second and they should go, or occasionally, you’ll need to close and open VSCode.

Running Javascript in VS Code

Tue, 27 Dec 2022 00:00:00 +0000

I’ve been using the Live Server plugin to see HTML & CSS updated as I edit, and that will also be useful when I start using Javascript for web development, but as you can see above, I’m not quite up to that. It seemed there should be a way to run JS in VS Code, and it turns out it’s easy.

You just need something installed that can run Javascript. Node.js is the obvious choice, and you’re going to need it later in your development journey. Just install Node.js then the first time you try to run some JS in VS code, it will ask you what to use, select Node and you’re in business.

I found out about this from here. I didn’t worry about Code Runner - just using Node.js worked for me without any fiddling beyond installing it (this is on Mac though - your Windows mileage may vary).

While I’m doing handy hints for dev tools, I discovered last night that the baby webserver that Live Server is running, isn’t just available on the local machine, it’s available to anyone on your network. Instead of using 127.0.0.1:5500, use the IP address of your development machine (but still port 5500 if that’s what you’re using). It’s an excellent way to look at your layout on phones etc, or, I guess, to see what other devs at your company are working on :- )

Who is Emmet?

Wed, 14 Dec 2022 00:00:00 +0000

I knew there was some magical way of entering all the the boilerplate in Visual Studio Code as I’d seen it happen in several videos, and assumed is was some sort of macro expansion thing in the editor. Fast forward a few blog post readings and youtube viewings and I keep seeing tangential references to someone called Emmet. Turns out they’re the same thing, and it’s pretty cool.

It’s not a new idea to have functionality in code editors to insert snippets of code. Emmet goes a bit further than that - and like many tools made by programmers for programmers it goes way to technical to the point where you need to memorise ridiculous amounts of combos to to some awesome stuff (I’m looking at you whoever made it possible to use vi commands in VS Code). Nevertheless, Emmet is extremely handy even at my n00b level.

The key thing to know, is that it borrows from the CSS selector syntax. So if you want to insert <div></div> you enter div and press tab.

Want a div with a class named “container”?

div.container becomes <div class="container"></div>.

The same trick works for an id - Enter

div#emmet becomes <div id="emmet"></div>

Would you like a div, with a heading inside? The greater than sign nests elements, so div>h4 becomes:

<div>
 <h4></h4>
<div>

If you’d like some text up in there, try div>h4{Hello world}

<div>
 <h4>Hello world</h4>
</div>

You can repeat things numbers of times, so to create a list with three items, try ul>li*3 to get:

<ul>
 <li></li>
 <li></li>
 <li></li>
</ul>

That’s about as complex as I’d want to get, though of course it gets more complex. It’s a super handy feature that quickly becomes second nature.