blog/coding-agents-in-secured-vscode-dev-containers

[stevenhuyn]

I was initialy drawn (misguidedly) to dev containers for their security. And have since been looking for a nice solution.

Have you noticed needing to update the configuration as vscode updates? Or is the devcontainer + vscode implementation very stable here.

[daaain]

@stevenhuyn

I was initialy drawn (misguidedly) to dev containers for their security. And have since been looking for a nice solution.

Have you noticed needing to update the configuration as vscode updates? Or is the devcontainer + vscode implementation very stable here.

Devcontainers is a standard with specs: https://github.com/devcontainers/spec/tree/main/docs/specs

And VS Code has a long page about their implementation: https://code.visualstudio.com/docs/devcontainers/containers

But I couldn't find the SSH forwarding and IPC sockets features properly documented in either.

So unfortunately this means it's a moving target, so I'll ask Claude to try to break out every now and then 😅 unless you have a better idea?

But in any case, this setup will be incomparably more secure than running on the host or vanilla container anyway!

[gilesknap]

Thanks for a great writeup. It has helped me finalise my own sandboxed Claude. I even wrote a skill that points at your blog and asks Claude to try and break out using your info!

I'm rootless with podman and have managed to make it so that users terminals get all the ssh key and git cred goodness but Claude gets none of the creds.

I also added GH cli PAT for Claude so it can write PRs and look at CI for me but not force push, change workflows or see any repos other than what I give it.

The approach to achieve this is removing access to sensitive folders and files using namespaces. That might also fly for rootful and avoids trying to delete socket files.

BTW I'm pretty sure vscode creates a new IPC socket for every terminal so your 5 minutes loop may not be enough.

If you are interested in my approach see gilesknap/python-copier-template.

[gilesknap]

Should have said pr #2

[daaain]

Hey, thanks a lot for sharing @gilesknap!

I'm not sure if I get the bit about new IPC socket for every terminal, you mean when opening an integrated terminal in VS Code that triggers it to recreate?

Namespacing Claude sounds like a great extra layer, I'll read up a bit more about it! I'm a bit worried about having to add CAP_SYS_ADMIN for unshare/mount calls though 🤔

I created a skill myself in the meantime, but forgot to update the post: https://github.com/daaain/skills/blob/main/skills/devcontainer-security/SKILL.md

I usually mix Terminal: Create New Integrated Terminal (Local) in the devcontainer with the internal container bash (so all the creds completely stay out of the container but I can still do stuff in the repo with the same IDE window using the local machine) and I haven't yet found a way to create a short lived Github token to hand to Claude for a specific task, but for GCP I have a solid setup with a user with read-only access by default (that can be temporarily elevated using Privileged Access Manager (PAM)) and then I can mint a token with a 1 hour expiry and inject it into the devcontainer to make the pre-installed gcloud work using:

gcp-elevate:
    gcloud beta pam grants create --entitlement=projects/<id>/locations/global/entitlements/pam-entitlement --requested-duration=43200s --justification="Development"

gcp-devcontainer:
    #!/usr/bin/env bash
    set -euo pipefail
    # Exact name match — docker's --filter name= is substring-based.
    container=$(docker ps --filter "status=running" --format '{{{{.Names}}' | grep -Fx "platform-devcontainer-{{worktree_name}}" || true)
    if [[ -z "$container" ]]; then
        echo "Error: No running devcontainer found for worktree '{{worktree_name}}'"
        exit 1
    fi
    token=$(gcloud auth print-access-token)
    docker exec "$container" bash -c "mkdir -p /tmp/gcp && echo '$token' > /tmp/gcp/access-token && gcloud config set auth/access_token_file /tmp/gcp/access-token 2>/dev/null"
    expires_at=$(date -d '+1 hour' '+%H:%M' 2>/dev/null || date -v+1H '+%H:%M' 2>/dev/null || echo "?")
    echo "✓ GCP access token injected into $container (expires ~${expires_at})"

[gilesknap]

Yeah, CAP_SYS_ADMIN in your rootful setup is more of a concern.

In rootless its not such a big deal (ask Claude about it!). I've been all in on devcontainers for around 5 years and I have found rootless to be a much better fit (and podman is fully supported by devcontainers now - it used to be a little fiddly). In rootless you are 'root' inside the container but the kernel sees you as being your host uid and so do host bind mounts - so there is no messing around with creating users inside the container file system.

Its worth noting that my sandbox for Claude drops all capabilities and forbids adding any.

re IPC sockets - yes when I open a new integrated terminal I immediately see an additional /tmp/vscode-ipc-... file.

Github fine grained tokens work in a similar fashion to gcp - just install the gh CLI and use my just recipie here. The shortest lifetime dropdown is 7 days but if you pick custom you can make it tomorrow's date. I paste my PAT directly into that 'read' and it gets cached for in a named container volume, surviving container rebuilds for the duration of the PAT.

[p-buddy]

Awesome article! I share your enthusiasm for containerizing everything / doing all development inside devcontainers, but I don't share all the knowhow... so much appreciated for sharing!

Based on a convo with claude, it seems like dropping 'VSCODE_IPC_HOOK_CLI' could lead to some degradation in claude's ability to integrate / interface with the editor -- does that track with your understanding and/or experience? Or have you been able to drop it with no noticeable loss?

If there is a loss, I'm wondering if re-enabling could be possible, and then just my restricting the allowed extensions we could make the case it's still secure (if I'm correct the main attack vector there is registering arbitrary extensions).

[p-buddy]

I've been experimenting with some further devcontainer hardening, specifically an environment where I don't want to disable container creation (things run under the agent profile, as you'll see below), and I've been using some claude code instances in devcontainers to try and 'escape'.

One instance just found: the env-scrub only unsets handles in shells (via BASH_ENV). The long-lived claude process (uid 2000, readable by agent) still carried VSCODE_IPC_HOOK_CLI=/tmp/vscode-ipc-…sock, recovered from /proc//environ; all four host-bridge socket names are also enumerable from world-readable /proc/net/unix. The env-scrub is therefore bypassable.
Why no crossing completed: the socket files are swept by the periodic compose sweeper and only re-created transiently during VS Code activity.

So at least a pen-testing claude agrees with what @gilesknap is mentioning, that those vscode sockets could be created at any moment, at will by vscode.

[pmalacho-mit]

(RE @stevenhuyn you might be right that vscode, if running in a "trusted workspace", might just be too leaky, but while I keep hammering on it...)

I just experimented with using TMPDIR to hopefully get vscode to write those sockets to a different place that I can ensure my agent profile can't touch, which maybe works..? 🤷‍♂️

Across these two commits (forgot to commit the Dockerfile changes at first):

• pmalacho-mit/secure-devcontainer-exploration@fbe1279
• pmalacho-mit/secure-devcontainer-exploration@1641f95

So the thought is, have the vscode profile use and read from a different tmp directory than the agent profile (which is both the profile used by claude code and any integrated terminals I open)

Banks on the fact vscode listens to the TMPDIR setting when writing those sockets, so I'll need to disengage the sweeper and test (haven't yet)

[pmalacho-mit]

(oops, should say that I am the same person as @p-buddy, just a work vs personal account)

[daaain]

Thank you so much for sharing and following up! I had my laptop in service and generally life's been going on so haven't got a chance to dig more into this, but just wanted to say that I was at a conference and Docker now has an alpha solution specifically for sandboxing: https://www.docker.com/products/docker-sandboxes/

That said, I did a bit of research and asked on the Docker Slack and so far no one has figured out how to make it work with VS Code, other than running code-server in the sbx container and using it in the browser – which is probably the ultimate secure solution, but not quite the same as having the app.

So still some way to go, but I think this is a very promising avenue!

[pmalacho-mit]

Ah, very interesting @daaain ! Thanks so much for sharing. Will definitely keep my eye on it, as it really feels like this is functionality that really requires some coordination between docker and VS Code (and trying to bandaid something together with claude code as I am isn't sustainable).

I look forward to a future where I can truly develop alongside an agent, and restrict both myself and the agent to only having an effect on that specific workspace.

[stevenhuyn]

This makes me wonder if vscode should be ditched and I just learnt cop the DevEx loss and use Helix.

…

On Fri, 5 June 2026, 1:45 pm Parker M, ***@***.***> wrote: I've been experimenting with some further devcontainer hardening, specifically an environment where I don't want to disable container creation (things run under the agent profile, as you'll see below), and I've been using some claude code instances in devcontainers to try and 'escape'. One instance just found: the env-scrub only unsets handles in shells (via BASH_ENV). The long-lived claude process (uid 2000, readable by agent) still carried VSCODE_IPC_HOOK_CLI=/tmp/vscode-ipc-…sock, recovered from /proc//environ; all four host-bridge socket names are also enumerable from world-readable /proc/net/unix. The env-scrub is therefore bypassable. Why no crossing completed: the socket files are swept by the periodic compose sweeper and only re-created transiently during VS Code activity. So at least a pen-testing claude agrees with what @gilesknap <https://github.com/gilesknap> is mentioning, that those vscode sockets could be created at any moment, at will by vscode. — Reply to this email directly, view it on GitHub <#7?email_source=notifications&email_token=AEMCKXAYN2PUBLQ4XHCR6CL46I67HA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRHA3TQNRWUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17187866>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMCKXGUZJVXQZVWCDSIUUT46I67HAVCNFSM6AAAAACXFBH2ZSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMJYG44DMNQ> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[gilesknap]

@pmalacho-mit well you could run your own terminals in the same or similar sandbox inside vscode. But it might be a challenge to get all of vscode's extensions to run in the sandbox, and that is your major attack surface for supply chain attacks (they all use npm packages!)

[gilesknap]

Which is why, my current plan is to switch editors to zed. I'll still use devcontainers via the CLI for now. Switching to zed's native devcontainer implementation when it lands. This is speculative for the moment gilesknap/thoth#171.

[pmalacho-mit]

Thanks, @gilesknap -- agreed, vscode certainly makes limiting the attack surface nearly impossible.

Zed is a great option to look out for.

Not sure about your OS, but on my Mac I've also begun experimenting with doing my development in a 'sandboxed' user (so vscode lives over there) and using an ssh tunnel for screensharing: REFERENCE

I then plan to leverage something like this configuration to run an mitmproxy server on my privileged user (and route all devcontainer traffic through it) to inject secrets into requests. That way, I'm only really at risk of an attacker seeing the source code of other repos, which for me is fine

Feels like such overkill (and I only got started down this road after reading this article and learning just how insecure devcontainers are -- I used to have a false sense of security). So an editor that takes security seriously sounds like a great option...

[stevenhuyn]

@gilesknap I'm in the radar for Zed too! They just need to get remote ssh DevContainers going so I can work with my older laptop on my good desktop. (hardware is pricy these days)

zed-industries/zed#56252

[gilesknap]

for those interested in claude-sandbox, I've done some more hardening and added documentation. https://gilesknap.github.io/claude-sandbox/

[gilesknap]

So I decided that I was also worried about lateral network egress because a rogue agent inside your LAN could still potentially find some attack surfaces without any credentials.

https://gilesknap.github.io/claude-sandbox 2.0 has network isolation via a userspace pasta network with restrcted routing. Like the filessystem isolation you can open up IP addresses explicityly if you want the agent talking to a device.

This is for your LAN only and still allows egress to the internet. If you want to limit internet access you have claude's built in sandbox for that.

Sorry to keep spamming your discussion talking about my project! I can't find anyone else on the internet actively discussing this issue. I tried to get some discussion going on reddit, but there does not seem to be huge uptake.

https://www.reddit.com/r/ClaudeAI/comments/1qimfr0/comment/osiukhm/?context=3
https://www.reddit.com/r/ClaudeAI/comments/1u9hfsh/claudesandbox_run_claude_code_in_developer/

Any links to useful discussion on this topic would be appreciated.

[nlgranger]

Hi! Do you know how the environment variables pointing to the sockets are set ? I tried to just read them in postAttachCommand and they seem empty at this stage. My goal was to remove any existing socket and create a read-only file in its place to prevent later creation. If they are dynamically update this won't work obviously, but I've never even heard about setting env vars dynamically.

[daaain]

Sorry for going quiet on this thread for so long – I've been busy building a new solution (and preparing a conference workshop about it) inspired by the discussions!

@nlgranger as far as I can tell those variables aren't set container-wide: the VS Code server injects them into the processes it spawns (each integrated terminal, tasks, the extension host), which is why they're empty in postAttachCommand. The socket names are randomised per terminal too, so a read-only placeholder can't guess them ahead of time. What worked better for me was two layers:

1. Stop VS Code installing the bridges in the first place. Set "git.terminalAuthentication": false and "git.useIntegratedAskPass": false so the git credential bridge (GIT_ASKPASS + its socket) never appears. For SSH agent forwarding, the attach forwards whatever SSH_AUTH_SOCK the VS Code process was launched with – and if it's unset, it goes looking for your real agent – so launch VS Code with SSH_AUTH_SOCK pointing at an empty ssh-agent you started for the purpose. One caveat: workspace settings beat user settings, and .vscode/settings.json is something the agent can edit, so check from inside the container too.
2. Clean up what's left from inside. Unset the variables in a script sourced on the very first line of ~/.bashrc (before the interactive guard, as in the post), plus a loop that removes /tmp/vscode-ssh-auth-*.sock and /tmp/vscode-git-*.sock as they appear. That's a race, which is why it's the second layer rather than the first.

@p-buddy in my experience unsetting VSCODE_IPC_HOOK_CLI hasn't hurt Claude Code – as far as I know its VS Code integration goes through its own extension running in the container rather than through that socket. The main thing I noticed losing is code some-file from the terminal opening in the editor window. Note that unsetting the variable doesn't remove the socket itself though, as you found via /proc – it's still there for anything that knows to look. Your TMPDIR split is a neat idea, I'd be curious whether VS Code honours it for all of the sockets! And the separate macOS user + mitmproxy injecting secrets on the way out is very close to where I ended up (below).

@gilesknap thank you again – rootless Podman was the nudge that sent me down this path, and you were right about the per-terminal sockets. On lateral movement: I went with a firewall inside the VM that refuses any direct connection apart from DNS and the proxy on the host, so the sandbox can't reach the LAN by itself. The weak spot is the proxy: it runs on the host and judges requests by hostname only. With the allowlist enforcing, a LAN address is refused unless you grant it – but during the initial learning window, or via an allowlisted hostname that resolves to an internal IP (DNS rebinding), it would connect to the LAN on the sandbox's behalf. Refusing loopback/private/link-local destinations at the proxy by default is next on my list, and I'd love to compare notes on how you handle it with pasta.

@stevenhuyn @gilesknap on Zed: I looked into it too, but when I checked in June its remote development was SSH-only, which would mean running sshd inside the sandbox. There's a reasonably tidy design (sshd -i behind a ProxyCommand that execs into the container, so nothing listens on the network) but I haven't built it – I'll revisit when Zed's dev container support lands (haven't checked in a while though).

So, without any further ado: meet Foldyard, an open source tool that runs your project's whole dev stack (compose services, installs, IDE backend and the agent) in a separate Lima VM per project that mounts only the repo, on rootless Podman. Credentials stay on your computer: a proxy there adds scoped tokens (short-lived ones where the service supports minting them) to outgoing requests, so the sandbox never holds them. fy verify checks the boundary from the inside, including whether VS Code has forwarded an SSH agent or git credential bridge into it. Docs are at https://twistco.github.io/foldyard/ – it's alpha, so issues and brave testers are very welcome!

Edit: corrected what I said about LAN access and what fy verify checks after having another look 😅

[gilesknap]

@daaain great to hear that you've put lots of effort into this. I'm trying to look at your work but both links are timing out for me at work, will try from home this evening.

I also encourage you to take a look at claude sandbox again because its come a long way and is super easy to install even without a devcontainer:

uvx claude-sandbox

[daaain]

@gilesknap I have been checking it and blatantly stealing getting inspired by your ideas, but I've gone extra paranoid and even on Linux use VMs (which also makes it easier to go cross-platform) and even offer the option to use gVisor as the container engine inside, so kernel exploits can't be a way out.

[gilesknap]

Ok maybe more paranoid than me. I'm explicitly not protecting against kernel exploits!

Your links are working from here, my work's firewall must have something against you. I'll have a play.

[pmalacho-mit]

Awesome stuff @daaain ! I too continued down this rabbit hole and arrived at something similar: https://github.com/pmalacho-mit/isolated-devcontainers-suede

If you don't have time to check that out, I totally agree with you on the major decisions:

1. Best to put the stack into a vm for isolation -- If I'm understanding right, you go with one vm per dev environment, but I opted for installing sysbox into the vm that colima maintains for me, and then run everything in nested containers within that vm. So I'm now locked in to mac for the time being.
2. You need an intercepting proxy for API key substitution

I'll continue in the tradition of blatantly stealing from getting inspired by foldyard and claude-sandbox!