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.

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.

Alternatively, the "feel free to leak all my data but please use my GPUs and don't rm -rf /" config:

  {
    "sandbox": {
      "enabled": true,
      "filesystem": {
        "allowRead": ["/"],
        "allowWrite": [
          ".",
          "/tmp",
          "/dev/nvidia0",
          "/dev/nvidia1",
          "/dev/nvidia2",
          "/dev/nvidia3",
          "/dev/nvidia4",
          "/dev/nvidia5",
          "/dev/nvidia6",
          "/dev/nvidia7",
          "/dev/nvidia8",
          "/dev/nvidiactl",
          "/dev/nvidia-uvm"
        ]
      }
    }
  }

Battle hardened tools for this have existed for decades, we don't need new ones. Just run claude as a user without access to those directories, that way the containment is inherited by subprocesses.

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?

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.

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.

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...

Any way to have it use /Users/claude/*? or something like that

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

Did you get this to work with docker where the agent/dev env would work on the host machine but the stack itself via docker compose?

Many of the projects I work on follow this pattern (and I’m not able to make bigger changes in them) and sanboxing breaks immediately when I need to docker compose run sometask.sh

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.

Interesting point. I've been running an autonomous multitalented AI agent (Aegis) on a $100 Samsung A04e. It manages 859 referring sites without touching the local filesystem much. Efficiency over hardware works."

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.

It will just do

    ssh you@localhost "rm -rf ~"

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

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

So what does this do exactly? If it used "default deny" or "default allow" you wouldn't have both allow and deny rules...

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.

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.

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.

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

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.

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?

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

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

what does this do?

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]