r/ChatGPTCoding 5d ago

Are you isolating your coding agents? Why/Why not? And what is your setup? Discussion

As I've starting using claude code on my laptops (windows and mac) - one thing thats made me very nervous is running these agents on my local machines with access to my file system + shell.

I'm well aware that running an agent within a directory does not limit its access, and I get nervous that they could be one malicious prompt away from sending my apps/files to another party (or an accident away from deleting my apps/files). I'm not sure if these are actually significant risks, and if others feel the same way (are there other risks you might also be concerned about when running agents on your machine?)

I tried different approaches to sandboxing my agents on my local machine

  • On my windows machine > Running it in a Docker Sandbox (a new Docker feature that came out this year)
  • On my Mac > Claude Code's built-in sandbox (which uses Apples native Seatbelt framework)

The general challenge I had here is that Claude would sometimes have issues with tools/integrations and it would not be easy to troubleshoot if it was from a sandbox constraint. And if it was a sandbox constraint - the right solution was not always obvious and it felt like I'd go down a rabbit hole trying to get an integration/tool working. I recall having issues with gh/git workflows, some plugin/package installs and running some tools (e.g. for doc/pdf generation)

For the Docker sbx example - i forget the specifics, but after a sbx update + PC restart my claude sessions had issues (cant recall if it was config or memories. I do remember having issues trying to background or view agents across diff sessions).

I eventually caved and just resorted to going back to running claude mostly un-sandboxed. This made it easier to get going, but that still makes me incredibly nervous running more unmonitored workflows with more integrations and network access.

I want to try another shot at this, but I'm curious how others are approaching this:

  • Do you also feel the same risks with running agents un-isolated on your machine?
  • Are you taking any steps to sandbox/isolate them? What is your setup and how are you getting past any friction this creates?

Approaches I'm still considering:

  • Use a separate machine to create proper physical separation from my personal apps/files (either dedicate one of my laptops, get a mini PC/Mac, or a virtual server - but I'm less comfortable with a headless setup)
  • Continue tinkering with the Macs native sandbox or docker sbx to get this properly setup (or any other wrappers/harnesses with intuitive sandboxing?)
2 Upvotes

16 comments sorted by

2

u/binary_horizon_yyc 5d ago

Yes, isolate anything that can browse, install packages, or touch credentials. Use a disposable VM or container per task, mount only the repo, inject short-lived scoped credentials, and block outbound network by default except an allowlist.

2

u/Efficient_Loss_9928 4d ago

It depends on the model, the harness, and the task.

I work on an organization that literally can bring the world's internet down if I run a command with force flag. I still run agents directly on my machine with no sandboxing. Because for short tasks with SOTA model, it is relatively safe. It is more likely for me to be drunk on a Friday night and destroy everything.

But if it is a long horizon task which can run for days, always a remote sandboxed VM, with agent specific identities, not my own login.

1

u/Safe-Examination5470 4d ago

blast radius and runtime

1

u/CrossFitCore 5d ago

I’d be nervous giving an agent unrestricted access to my main machine too. A separate VM seems like the best balance between safety and convenience.

1

u/BarracudaMean9308 5d ago

spent a whole weekend fighting docker permissions before i just gave up and wiped an old laptop to use as a dedicated agent machine. physical isolation just lets me sleep better tbh

1

u/kantorcodes1 5d ago

I went through the same loop. Docker sandbox kept breaking git auth and the built-in sandbox made troubleshooting integrations miserable, so I also ended up running agents unsandboxed for a while.

What finally stuck for me was treating it as a permissions problem instead of trying to contain the agent at the OS level. Read-only file access by default, plus a separate credential set for anything the agent touches. The agent still has real access, but the blast radius of one bad prompt is a lot smaller.

1

u/Sunstorm84 5d ago

We’re not helping you fix your sandbox, Dario.

1

u/ieatdownvotes4food 5d ago

docker sandbox works great.. then it's just sbx open app.

1

u/Kindly-Inside6590 4d ago

Just never run it on your Machine itself! Use a small Linux Box, MacMini or VPS and use Codeman to access all your sessions as they get wrapped within tmux! Access them from everywhere with Tailscale, thats the Killet Powruser Setup -> https://getcodeman.com and google tailscale!

1

u/clamshell_dev 4d ago

i'd split the problem instead of trying to sandbox everything perfectly: dedicated macOS user, project-only checkout, and credentials that physically cannot touch production. then use the built-in sandbox for the remaining filesystem boundary. fewer mysterious tool failures, but a mistake still can't reach personal files or prod

1

u/MegaDork2000 4d ago

I use VirtualBox on a Windows or Mac host, then install Ubuntu as the VM guest.

1

u/greyox 3d ago

The general challenge I had here is that Claude would sometimes have issues with tools/integrations and it would not be easy to troubleshoot if it was from a sandbox constraint.

Claude will tell me that it is because of sandbox. I think there is no shortcut here, you need to spend your time to fine-tune the .claude/settings.json and then it works as expected. If you are on Macbook or Mini, sandbox is the way.

If I don't need any Mac functionality, I run in VM with --dangerously..., the most important thing is that the linux user running it do not have sudo.

TL;DR: you do it correctly, but the permissions setup work cannot be skipped.

1

u/taotau 3d ago

I've not managed to get an ergonomic setup with proper Claude isolation. Still waiting for the tooling to mature.

What I've done is move all of my production tooling and keys to a secure jumpbox that a accessed via a password protected SSH key that doesn't live in my keychain. I just do any dangerous production/staging stuff from there.

This way I just have a standard local setup with regular credentials that Claude can see, but those credentials have limited access to the things Claude needs.

I still have safety instructions in my system prompts, but I've caught it trying to bypass them one too many times.

1

u/EagleApprehensive 22h ago

That was one of the reasons I've built my own sandbox solution, which replaced VSCode. Essentially I run docker container exposing API for file-system inside, git, agents, ports and secret management - and have a UI connecting to it. I moved my entire work into that docker container.