Let's Talk About Claude Code, Part 1: Where Is Your Agent Actually Running?
I've watched a coding agent wander out of its project folder and start reading other client repos on the same laptop. It wasn't doing anything malicious. It was trying to be helpful. But some of those repos had productio
I've watched a coding agent wander out of its project folder and start reading other client repos on the same laptop. It wasn't doing anything malicious. It was trying to be helpful. But some of those repos had production credentials in them, and they all got rotated that afternoon.
Most discussion about coding agents is about which model to use. Much less of it covers where the agent runs, and that's where most of the risk is.
What an agent on your host can reach
Run Claude Code directly on your machine and it runs as you. Whatever your user account can read, it can read too, including:
- SSH keys in
~/.ssh - Cloud credentials in
~/.aws,~/.config/gcloudand similar - Every
.envfile in every project on the disk - Every other repo you've cloned, including ones for other clients
That last one is what caught me out. Nobody worries about the agent reading the repo it's working in. The problem is everything else that happens to be on the same disk.
Why permission prompts aren't enough
Claude Code asks before it runs commands or touches files outside the working directory. That works for the first few prompts. By the fortieth in a session you're approving without reading, or you've turned on skip-permissions so they stop interrupting you.
Prompts depend on a human paying attention every time. That's a weak control to build on.
What I do now
Every project now runs in a Docker Sandbox (sbx). Each agent gets its own microVM, and the only part of my machine it can see is the project folder.
Two things to know before you switch:
- sbx starts Claude Code with permission prompts skipped by default. That's deliberate, because the VM is the boundary instead of the prompts. It does mean the agent will act without asking inside the sandbox.
- Your project folder is still shared. The agent can delete or break anything in the repo. Commit often, and keep secrets out of the working tree.
Next in the series
Part 2 covers why I went with sbx over a plain dev container, and what a container doesn't protect you from.
How are you running your agents? Directly on the host, in a container, or in a VM? Tell me in the comments.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.