No question needs answering. If you want to run claude code inside sandboxed environment, it's not that hard and there are lot of options including official[0].

[0]: https://code.claude.com/docs/en/sandboxing

From the doc, this suggestion is hardly satisfactory:

The sandbox covers shell commands only. Claude’s file tools, MCP servers, and hooks run outside it.

Also this is in my view the main job of a scaffold like claude code - to restrict what the agent can see and make sure it doesn't use info it should not. It's not something a user can easily or should have to attempt to control themselves.

File tools, by default asks permission to edit outside directory. There is no MCP tools or hooks by default and if you install it you need explicit permission to trust it.

These CLI sandboxes are trash, use something else. Container, VM, not your computer. Just don't run it on your bare system, please.

I usually run claude sandboxed, but had to do something on Windows and didn't want to be bothered. Opened a project, asked something generic about it and in the first response Claue tells me it tried to fetch all URLs it found it in it and what errors were in responses. Cool stuff.

Yes, they need to be heavily sandboxed. On my machine, LLMs are constrained to docker containers for me, no exceptions.

Launch script checks that I can't accidentally run them with a working dir too far out (i.e. user folder).

> Should Claude have access to user details?

This is hard to avoid. All it needs to do is make a git commit and look in the git log and it will find out who you are.

At least we, as users, have control of what information Claude has access to in this case:

  - Option 1: Don't give Claude the `.git` directory
  - Option 2: Build a `.git` anonymizer that overwrite git history with bogus emails

etc.

That's barely control. There's going to be 100 ways your email leaks.

Yeah but leaking because Anthropic leaked your email vs. you underengineered your sandbox are two very different failure modes imo.

LLMs are supposed to be a panacea for building digital systems. A sandbox inside which an LLM can operate freely surely should be one of the first systems we should all strive to engineer.

If we can't properly sandbox an LLM, I would say that's a pretty good sign that LLMs are not a panacea for building digital systems.

Even if they’re not a panacea we have to accept the reality that all enterprise IT environments have at least some level of LLM exposure and figure out a way to manage the situation.

Why does it need to perform a commit to read the log?

The repo's other commits could be from someone else - whereas a commit it wrote itself is guaranteed to be from the correct/local account.

Can it not check the current credentials that it would potentially be using to make said commit?

Sure, I was providing an example of how it could be done, not an exhaustive list.

I am developing a project to sandbox AI coding agents at very basic level: https://github.com/daitangio/take-ai-control

I would also like to add a list of allowed site, closing all the others, but it is quite complex from docker.

It is not safe like a isolated VM, but it is a good trade-off to avoid letting a model to wipe out all your home directory or looking into other files in your disk.

As always feedback is wellcomed

> I would also like to add a list of allowed site, closing all the others, but it is quite complex from docker.

Maybe use two containers in the same docker network. One docker container has the agent and is not allowed to leave the network. The other container you'd run a proxy in with whitelisting and that container is allowed to leave the network.

Why not use a microVM instead of a container ?

You want a VM, not a container, because VMs are harder to escape.

since my employer is compelling me to throw out my expertise and rot my brain with Claude, I've been using clawk to sandbox instances in VMs: https://github.com/clawkwork/clawk

It's not perfect, but it works pretty well, and has done a nice job of forcing me to think through exactly what I'm allowing Claude access to and why, and what the risks are.

> Should Claude have access to anything outside of the sandboxed project files without explicit permission? I’d again say no.

This is definitely a question that sounds straightforward but isn't. Like, when I ask antigravity to commit to git, it gets an error because ~/.gitconfig is outside the sandbox.

Sure, it's a hard problem, that doesn't mean we shouldn't tackle it. It is in fact one of the more urgent problems for Anthropic to address properly.

I'd feel a lot safer granting fine grained permissions like that, than knowing that the only thing stopping the LLM reading files is that it hasn't thought to do so.

I mean, I think Claude has some controls on file access, but I'm not exactly sure any more what is and what isn't allowed. The impression their desktop app gives is that you need to give permission for each and every file or folder access, but I'd feel a lot safer if that were imposed by an operating system level constraint, not claude trying to read the use of tools and ok/disallow them based on what an llm thinks.

It seems very unlikely that "leaking email addresses" is anywhere near being "one of the more urgent problems for Anthropic". This is a company whose training models occasionally commit felonies, and whose IPO documents claim that they might potentially kill all of humanity.

This is not just about email addresses. It’s a bigger problem than that.

The models are very aggressive in finding the info they need. I had one find some API key somewhere so that it can make requests. Sloppy on my part of having API keys not related on the hard drive but was not expecting the model to burn my harddrive in a lookup for api keys.