sandbox: filesystem reads are unrestricted, and the agent can silently break its own sandbox enforcement by editing settings.json

Since I've been evaluating sandbox functionality for my team's use, I'm pretty shocked that these issues haven't been fixed yet.

I was able to reproduce the "invalid settings.json mid-session breaks sandbox" (and ALL other permission settings!) bug:

Reproduction: permission enforcement fails open once settings.json becomes invalid JSON

I reproduced this to see if Claude Code would respect a self-protecting deny rule in settings.json.

Setup

• ~/.claude/settings.json contained a permissions.deny block that explicitly protects itself from edits:

"deny": [
  "Edit(settings.json)",
  "Edit(settings.local.json)",
  "Edit(~/.claude/settings.json)",
  "Bash(rm * settings.json)",
  "Bash(rm * settings.local.json)"
]

• theme was "light".

Step 1 — Edit correctly denied (valid JSON, rule intact)

Asked Claude to change "theme": "light" → "theme": "system" via its Edit tool. Result:

Error: File is in a directory that is denied by your permission settings.

(Note: that message is also strange, as the deny permission is on the file, not the directory.)

Correct — Edit(settings.json) in the deny list was enforced as expected.

Step 2 - Manually create malformed json

Removed the comma in the line before 'theme'.

  "tui": "fullscreen"
  "theme": "light",

Step 3 — Retried the identical edit

Same Edit call, same target string. This time the edit succeeded.

Claude stated that it expected the same result as my first request, then was surprised that its edit went through, and flagged the incorrect JSON that didn't result from an edit in the session.

The issue was reproduced - if you make settings.json invalid mid-session, this isn't flagged, and permission rules (as well as any other settings) are then ignored.

Expected behaviour

settings.json should be validated in the harness on every user prompt and before anything else happens, so that Claude Code will never run without permission or sandbox settings!

It's possible for settings.json to be set and enforced from a Managed Device setup, which means that users could have malformed JSON without their knowledge and without it ever being flagged until they ask Claude Code to actually look at the file or until they start a new session (that's when settings.json is actually validated).

Additionally, the sandbox.credentials schema the OP said is hallucinated, is part of the official spec, and I can confirm it works as expected (setting a canary dir / file to 'deny' or 'mask' blocks reads). Note: I'm working on macOS, so that might yield a different result!

https://code.claude.com/docs/en/settings-reference#sandbox-credentials

I let Claude write this whole issue, but confirm it did indeed read my ~/.ssh/id_rsa.

I'm so pissed off about this that I honestly can't be bothered to have Anthropic fix this. I don't trust their skill level or commitment.
I've created my own sandbox, that I fully understand using bwrap on Linux; I know this one works, and am sure Claude can not get out of it.

Here's the article that I based my script on. Mine is a minor modification of the article, because I use different programming languages, but this is a great basis.

Independently measured the same two problems, and I can add a third interaction that is not obvious and that bit us.

On the read side. Confirmed: there is no read-restriction primitive, and permissions.deny only covers the dedicated Read tool, not cat or grep through Bash. Two further measurements:

• permissions.deny does fire under bypassPermissions, but only while the sandbox is enabled. With the sandbox off it stops applying. So the deny list and the sandbox are not two independent layers; either one alone is decorative.
• allowWrite does not re-open a region that a deny pattern covers, and the working directory is not exempt from a deny pattern either. Worth stating in the docs, because both are easy to assume the other way round.

On the self-disabling problem. Agreed that a settings file inside the agent's own writable tree cannot enforce anything against that agent. What worked here was moving the boundary under the process rather than beside it: a kernel sandbox profile built by the parent, (deny file-write*) followed by an explicit list of allowed regions, with the agent's own settings file outside every allowed region. The agent can then edit whatever it likes and the boundary does not move, because the boundary was never in a file it can reach.

The interaction that cost us a day, and it is the reason this is not a two-line fix. A sandbox that denies writes refuses a sandbox nested inside it. Not nesting in general, which works, but nesting inside a profile whose first line is (deny file-write*). So an outer kernel jail requires telling the CLI sandbox.enabled: false, and that in turn drops the CLI's own network enforcement, which is the subject of #89165. The two controls are coupled in a way neither one documents.

Measured on macOS. Happy to share the profile and a repro if useful.

Measured on macOS 15, Apple silicon, claude 2.1.233. The settings keys involved are unchanged in 2.1.246, checked today.

Context, since it is fair to say where this comes from: measured while building Januas, a vendor-neutral supervision and containment layer for coding agents. Not released, nothing to sell you; the measurements are the only reason for this comment.

Regarding the core architectural issue where in-tree settings.json / permission prompts can be bypassed via child Bash commands (cat ~/.ssh/id_rsa) or malformed JSON states:

As @Orellius and @bvdeenen noted, relying on an in-process agent harness to police its own tools is structurally flawed because:

1. Internal tool filters (like Read permission checks) do not restrict raw syscalls executed by child shells (bash, python, curl).
2. If settings.json is writable by the agent (or if its parser fails open), permission enforcement collapses entirely.

To solve this deterministically without requiring root or custom shell scripts, we built Vetto as an operator-controlled, pre-execution kernel boundary:

# 1. Install standalone (no Node/daemon required) or via npm
curl -fsSL https://raw.githubusercontent.com/shleder/vetto/main/scripts/install.sh | sh
# or: npm i -g @shledery/vetto

# 2. Run Claude Code inside an outer kernel perimeter:
vetto --agent claude --profile strict --net=off -- claude -p "refactor codebase"

How the boundary works at the OS layer:

• Kernel-enforced Landlock / Seatbelt: Read/write access is restricted at the VFS/syscall level before the agent process is spawned. All child shells, cat, grep, or subagents inherit the restriction automatically.
• Fail-Closed Secret Masking: $HOME/.ssh, ~/.aws, and .env files are mapped directly to /dev/null and directories to empty tmpfs. Even if Claude Code attempts cat ~/.ssh/id_rsa through Bash, the kernel returns EOF (0 bytes).
• Out-of-Tree Policy: Policies reside in immutable operator memory, completely inaccessible to the agent runtime. The agent cannot disable its own sandbox by editing local configuration files.
• Zero Daemon / Zero Telemetry: Native Rust binary utilizing unprivileged user namespaces and Landlock ABI 1-4 on Linux and Seatbelt on macOS.