Add this to .claude/settings.json:

  {                                                                                                                                                              
    "sandbox": {                                                                                                                                               
      "enabled": true,
      "filesystem": {
        "allowRead": ["."],
        "denyRead": ["~/"],
        "allowWrite": ["."],
        "denyWrite": ["/"]
      }                                                                                                                                                          
    }
  }

I've seen claude get confused about what directory it's in. And of course I've seen claude run rm -rf *. Fortunately not both at the same time for me, but not hard to imagine. The claude sandbox is a good idea, but to be effective it would need to be implemented at a very low level and enforced on all programs that claude launches. Also, claude itself is an enormous program that is mostly developed by AI. So to have a small <3000-line human-implemented program as another layer of defense offers meaningful additional protection.

You do also have to worry about exec and other neat ways to probably get around stuff. You could also spin up YAD (yet another docker) and run Claude in there with your git cloned into it and beyond some state-level-actor escapes it should cover 99% of your most basic failures.

I think the point would be that - some random upcoming revision of claude-code could remove or simply change the config name just as silently as it was introduced.

People might genuinely want some other software to do the sandboxing. Something other than the fox.

I've had issues with the sandbox feature, both on linux (archlinux) and two macos machines (tahoe). There is an open issue[1] on the claude-code issue tracker for it.

I'm not saying it is broken for everyone, but please do verify it does work before trusting it, by instructing Claude to attempt to read from somewhere it shouldn't be allowed to.

From my side, I confirmed both bubblewrap and seatbelt to work independently, but through claude-code they don't even though claude-code reports them to be active when debugging.

[1] https://github.com/anthropics/claude-code/issues/32226

Also, a lot of people use multiple harnesses. I'm often switching between claude, codex, and opencode. It's kind of nice to have the sandbox policy independent of the actual AI assistant you are running.

Is this a real sandbox or just a pretty please?

Cool. Does opencode.ai have such a feature also (sandboxing with bubblewrap)?

Interesting, thanks. I use remote ephemeral dev containers with isolated envs, so filesystem damage isn't really a concern as long as the PR looks good in review. Nice extra guardrail though, will add it to the project-level settings.

For some reason, this made everything worse for me. Now claude constantly tries to access my home folder instead of current directory. Obviously this is not still good enough. Also Claude keeps dismissing my instructions on not to read my home directory and use current directory. Weird.

The default: https://code.claude.com/docs/en/sandboxing#filesystem-isolat... already restricts writes to only the current folder. I can understand adding the "denyRead" for the home folder for additional security, but the other three seems redundant considering the default behavior.

FYI, this doesn’t always work as expected. Try asking Claude to read “~/.ssh/config” with these settings and it will happily do it.

Specifically, it only works for spawned processes and not builtin tools.

It’s cute because Claude has discretion to disable its own sandbox and does it

I’m surprised it works for you with such a simple config? I’m the one that added the allowRead option to Claude’s underlying sandbox [0] and had quite a job getting my toolchains and skills to work with it [1].

[0] Fun to see the confusing docs I wrote show up more or less verbatim on Claude’s docs.

[1] My config is here, may be useful to someone: https://github.com/carderne/pi-sandbox/blob/main/sandbox.jso...

It's common practice to ask the agent to refer to another project, in that case I guess the read should point to the root folder of the projects.

Also, any details on how is this enforced? because I notice that the claude in Windows don't respect plan mode always; It has edited files in plan mode; I never faced that issue in Linux though.

So in some sense we start recreating an operating system, or at least the userspace, within the Claude code. There was some name for this pattern but I can’t recall

I'm now considering installing QubesOS for all dev work to absolutely ensure all coding agents run in secure separate sandboxes together without any OS level exposure.

It will just do

    ssh you@localhost "rm -rf ~"

And you'd trust that given CC is a vibe-coded mess?

Editing to go even further because, I gotta say, this is a low point for HN. Here's a post with a real security tool and the top comment is basically "nah, just trust the software to sandbox itself". I feel like IQ has taken a complete nosedive in the past year or so. I guess people are already forgetting how to think? Really sad to see.

I use bbwrap to sandbox Claude. Works very well and gives me a lot of control and certainty around the sandbox.

Does this also apply to the commands or programs that it runs?

e.g. if it writes a script or program with a bug which affects other files, will this prevent it from deleting or overwriting them?

What about if the user runs a program the agent wrote?

Is this a hard sandbox (enforced outside the LLM)?

I noticed codex has a sandbox, wondering if it has a comparable config section.

Is that hard setting or does it depend on claude’s interpretation?

The latter could end like this https://news.ycombinator.com/item?id=47357042

lol if you think Claude is smart enough to block sneaky path strings based on your config.

[dead]