It's March 2026 and everybody is using Claude Code or at least experimenting with it. But Claude Code introduces some significant security risks. This article is about how I personally decided to deal with those risks.
tldr;
If you just want a quick solution for running claude in an isolated podman container with some comfort features, check out ai-pod.
Existing Solutions
Let's go through the obvious options and see why they did not feel sufficient:
Just set individual per-command permissions.
Claude Code will, by default, ask the developer for permissions for each command and suggest some default permission for repeated uses of the command, e.g. it will suggest to allow reads and writes generally and specific bash commands with wildcards for arguments such as ls *, git add * etc.
This setup has three downsides:
There is no practical way to prevent Claude from reading the entire file system.
This becomes insecure fast because Claude asks for a lot of permissions which leads to fatigue: you just start accepting the requests after a while.
It is inefficient because Claude asks for permissions all the time which cripples my workflow.
Claude's own sandbox
Claude Code comes with a /sandbox command which puts claude in an isolated shell.
This won't work for me because
It still allows Claude to read the entire file system and expose all my secrets to Anthropic (and potentially other parties through prompt injection and web fetch / curl)
I find myself dropping back out of the sandbox frequently because Claude gets stuck not being able to use host ports and other resources.
container-use
container-use is a tool to run commands in a dedicated container/vm using dagger/docker. It exposes an MCP through which Claude can put itself in an isolated environment.
Then Claude sets up its own sandboxed environment, works on some changes and I can review and pull those changes to the host using regular git commands.
This is fairly clever but I found myself struggling with the setup and also figured what I want is a more direct collaboration. I actually want Claude to run against a repo in my local filesystem so I can immediately see the changes and follow along.
Another issue with this flow is that for a lot of the apps I build, I'll need secrets to run them. In order for Claude to run an app like this in its isolated environment I need to expose the secrets to Claude which I would prefer to avoid if possible.
Online Sandboxes
IaaS/PaaS providers are rushing to provide AI-ready Sandboxed VMs to their customers, see the offerings from vercel or fly.io.
These sandboxes are nicely isolated and provide some pretty useful features.
But then again I actually do not want to put the secrets to run my apps in the Sandbox and I also want to see results immediately, without a git workflow in between.
My solution
I figured that podman might be just the tool I need and I have it set up anyway because I use it to host the dev environments for my projects (postgres databases etc). It provides isolation by running an unprivileged VM (called a podman machine) in which all containers will run as well as a very comfortable way to map just the specific folders I need into the container that runs Claude Code.
Now the Setup I built works like this:
I build a docker image per project. This image contains all kinds of tools that will be useful for Claude in this particular project. In a Next.js repo it might be based on the node docker image and have the Next.js MCP server preinstalled. It creates a user
claudethat will run the actual CLI.I have a docker volume for the home directory (
/home/claude) that persists settings and auth between multiple sessionsI run one container per session. Usually that's one per project, sometimes multiple in parallel, sometimes I detach and run them in the background.
The project directory is mounted into the container as a volume
All dotenv files are actually stored in a central location (
~/.env-files) and symlinked into the project directories so they are not visible inside the ContainerI run the dev server on the host and tell Claude to check it out on
http://host.containers.internal, the URL referring to the host in podman networks. This way claude can see what it is building without access to any of the secretsThen I just grant claude all the permissions it wants, in particular I let it run wild on Bash as all commands will be run in its isolated container environment.
Is this perfectly safe
No it is not.
Claude can escape the container and at least get access to all other containers running in the same VM.
It can check bad code into my repo (this risk is inherent to agentic development and unavoidable and the reason why I will make sure that a human has checked all the code before it gets merged).
It can modify the code to do bad things and immediately execute the bad code by fetching some route on the dev server I run on the host. I live with this risk for now but am looking for mitigation strategies.
That said it seems like the biggest vulnerabilities right now are
Environment extraction through prompt injection attacks. The attacker would have to know my setup pretty well and convince Claude to do a lot of unwanted behavior to get to my environment with my setup
Claude seems to nuke (
rm -rf) large parts of its user's filesystems every once in a while. This cannot happen with my setup
This sounds complicated
I built a tool called ai-pod that does the heavy lifting (creates an example ai-pod.Dockerfile, runs the containers with the right mounts and even forwards notifications when claude is finished to the host system)
I've been using ai-pods for all my claude sessions for a while now and it doesn't feel like a burden compared to natively running claude. It even prevents cross-project context pollution (every project has its own claude settings and history).
Summary
Running Claude Code inside a container is the approach that works best for me. It gives Claude the freedom to run bash commands without constant permission prompts while keeping it away from my secrets, my home directory, and the rest of my system. The key insight is separating what Claude needs to build the project from what the project needs to run — by keeping secrets out of the container entirely and running the dev server on the host, Claude can iterate effectively without ever touching sensitive credentials.
It is not a perfect sandbox and it does not pretend to be. But it meaningfully reduces the attack surface for the threats I care about most: secret extraction through prompt injection and accidental or malicious filesystem destruction. For everything else, code review remains the last line of defense.
If you want to try this setup yourself, check out ai-pod. It takes care of the boilerplate so you can focus on building.
