I recently started using Visual Studio Code Dev Containers with LLM coding agents and I thought to share it because, in my opinion, it is one of the simplest ways to make agentic development safer.
LLM agents are incredibly useful, but the first time you run one with full access to your laptop you may have the same thought I had:
"Do I really want this thing to see my whole filesystem, my SSH keys, my cloud credentials, and all the random projects I have locally?"
Developer Experience
The best developer experience is not only about speed.
It is also about having an environment where you can experiment without constantly worrying about what the tool can touch.
This is where Dev Containers are very useful: you can give the agent a clean workspace, the exact dependencies it needs, and nothing else.
Visual Studio Code Dev Containers
The Visual Studio Code Dev Containers extension lets you use a Docker container as a full-featured development environment. It allows you to open any folder or repository inside a container and take advantage of Visual Studio Code's full feature set.
For LLM agents, this means you can run the editor, terminal, tools, and agent inside a container instead of directly on your machine.
The agent can still edit files, run tests, install packages, and execute commands, but only inside the environment you prepared for it.
Why This Matters For LLM Agents
When you run an agent locally, the risk is not only that it writes bad code.
The bigger concern is access.
If your whole home directory is available, the agent may accidentally read files that are unrelated to the project. If your shell has access to credentials, tokens, cloud CLIs, SSH config, or production scripts, the blast radius is much bigger.
With a Dev Container you can avoid sharing all your system and credentials. You mount only the project folders you want to work on, install only the tools needed for that environment, and decide explicitly which secrets, if any, are available.
YOLO Mode
Many LLM coding tools have a mode where the agent can run commands and edit files without asking for confirmation every time.
Sometimes people call this "YOLO mode".
It is convenient, but on your host machine it can be scary.
Inside a Dev Container, it becomes much more reasonable: if the agent installs the wrong package, breaks the environment, or creates a mess, you can rebuild the container and start again.
You are not giving it your entire laptop.
You are giving it a disposable development box.
My Setup
Instead of adding a .devcontainer folder to every project, I keep one separate folder that only describes the agent environment.
Something like this:
.
|-- devcontainer
| |-- devcontainer.json
| `-- Dockerfile
|-- project-a
|-- project-b
`-- project-c
I build and start the container from the devcontainer folder.
Then, when I want to work on a project, I attach that project folder into the running container and connect VS Code to the container.
This gives me one reusable environment for LLM agents, without having to copy the same Dev Container configuration into every repository.
Configuration
devcontainer.json
The devcontainer.json file describes the reusable container environment.
Here is a simple example:
{
"name": "agent-safe-workspace",
"build": { "dockerfile": "Dockerfile" },
"workspaceFolder": "/workspaces",
"remoteUser": "node"
}
The important idea is that this folder describes the agent box, not a specific application.
Your projects can stay separate, and you decide which ones are attached to the running container.
Dockerfile
The Dockerfile defines what is installed inside the container.
For example, for a Node.js based environment:
FROM mcr.microsoft.com/devcontainers/javascript-node:1-22-bookworm
RUN apt-get update && apt-get install -y \
ripgrep \
jq \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /workspaces
You can adapt this depending on your stack: Python, Go, Rust, Java, or anything else.
The important part is that the dependencies are installed in the container, not directly on your host machine.
Starting The Container
From the folder that contains the Dev Container configuration, you start the container separately.
For example, you can use the Dev Containers extension to open only that devcontainer folder, or you can build and run the Docker image yourself.
After the container is running, attach VS Code to it with:
Dev Containers: Attach to Running Container
At that point you are inside the isolated environment.
Then you attach or mount the project folder you want to work on into the container and open it from there.
The workflow becomes:
1. Start the reusable agent container
2. Attach your project to the running container with VS Code
3. Run the LLM agent inside the container
This is different from the usual flow where each project owns its own .devcontainer folder.
In this setup, the container is the stable tool environment, and the project folders are the inputs you choose to expose to it.
Credentials
Be intentional with secrets.
Do not mount your entire ~/.ssh, ~/.aws, ~/.config, or home directory by default.
If the agent needs a token, create a limited token for that task. If it needs GitHub access, prefer a token with the smallest useful scope. If it does not need credentials, do not provide them.
The point of the container is to make access explicit.
Docker
Obviously, you need Docker up and running on your machine.
After that, VS Code can connect to the container and give you the usual editor experience inside the isolated environment.
VS Code Extension
To use this workflow, install the Dev Containers extension.
The command I use most in this setup is:
Dev Containers: Attach to Running Container
This lets me keep the container lifecycle separate from the project lifecycle.
Ready To Go
Once the container is running and the project folder is attached, start your LLM agent from the VS Code terminal inside the container.
Now the agent sees the project workspace and the tools you installed there.
That is the main advantage: you can let the agent move faster, even in YOLO mode, while keeping a clear boundary between the experiment and the rest of your machine.
It is not a magic security solution, but it is a very practical improvement. The only tedious part is writing the correct Dockerfile, but once it is done, the environment becomes reusable, predictable, and safe to use.
For day-to-day agentic coding, a reusable disposable Dev Container is one of the easiest ways to reduce risk without making the workflow painful.
You can follow me on GitHub, where I'm creating cool projects.
I hope you enjoyed this article, until next time 👋
Top comments (1)
Guilty 🦄😂🦚