Claude Code settings.json Permissions: 2 Denials, 1 Logged

My rig runs six unattended Claude Code scripts, and every one of them passes --dangerously-skip-permissions. Until tonight I could not have told you whether anything in settings.json still applied inside those runs. So I audited my own files before running any experiment, and the audit was short.

File	What is in it
~/.claude/settings.json (5,550 B)	One permissions key: defaultMode: "auto"
~/.claude/settings.local.json (699 B)	permissions.allow, 19 rules
.claude/settings.json in the repo	Does not exist
Managed settings	Does not exist
deny rules, all scopes	0

The 19 allow rules were never designed. They are sediment from interactive sessions where I clicked the option that means yes and stop asking: Bash(bash *), Bash(node *), Read(//opt/homebrew/bin/**). Every rule I own opens a door. Not one closes a door.

So the useful question was not how I had configured permissions. It was what a deny rule would have done if I had written one, inside a run that already declares it is skipping permissions.

The instrument

Claude Code 2.1.227 on a Mac mini M4, macOS 26.4.1. I made a scratch directory at /tmp/permprobe holding two files, marker.txt containing SECRET-MARKER-8F2A and other.txt containing OTHER-FILE-CONTENT-9911. The only thing I changed between probes was the project-level .claude/settings.json. Nine probes, all through claude -p with --output-format json or stream-json, all on the default model, because my unattended scripts do not pass --model either.

The CLI states its own position clearly. From claude --help, verbatim:

--dangerously-skip-permissions        Bypass all permission checks.
                                      Recommended only for sandboxes with no
                                      internet access.

Deny survives the flag, and that part is not my discovery

With "deny": ["Bash(cat:*)"] in the project file and no flag at all, asking for cat marker.txt was blocked. With the same rule and --dangerously-skip-permissions, it was blocked again. I then tried to out-rank the rule from the command line, since the official settings reference puts command line arguments above project settings in its precedence list, second only to managed settings. Running with both the skip flag and --allowedTools "Bash(cat:*)", it was still blocked.

So deny is not a high entry in the precedence chain. It sits outside it. The flag whose help text says it bypasses all permission checks does not bypass this one.

I want to be exact about credit here, because it would be easy to dress this up. Several secondary write-ups already say deny rules win over bypass mode. What I can add is that it holds in 2.1.227 under the exact conditions my fleet runs in, and that the two official pages I checked, the settings reference and the permissions guide, do not state the interaction at all. The confirmation is worth something. The interesting results came from the probes after it.

The rule is a filter on a string, not on an outcome

Probe 2 and probe 3 have identical settings. Only the prompt differs. Probe 2 named the command, so the rule fired. Probe 3 asked what is inside marker.txt, without naming a tool, and got back the contents of the file.

Nothing was circumvented. The agent went to the Read tool, which no rule mentioned, and Read is not cat. The part that matters for an unattended fleet is the record. The result envelope for probe 3 carried permission_denials: []. The rule was not defeated, it was never consulted, and in the machine-readable output that run is indistinguishable from a run with no rules in play.

This is the shape I found in July when I tested the built-in sandbox on this rig: block the shell and the work reroutes through the file tools. Same shape, one layer up.

Two denials, one logged

So I denied both paths, "deny": ["Bash(cat:*)", "Read(./marker.txt)"], and asked for both tool calls explicitly in one session. Both were refused. Here is the stream, trimmed to the four lines that matter:

TOOL_USE  Bash {"command": "cat marker.txt"}
TOOL_RESULT err=True | Permission to use Bash with command cat marker.txt has been denied.
TOOL_USE  Read {"file_path": "/private/tmp/permprobe/marker.txt"}
TOOL_RESULT err=True | <tool_use_error>File is in a directory that is denied by your permission settings.</tool_use_error>
PERMISSION_DENIALS count= 1
   -> Bash {"command": "cat marker.txt", ...}

Two deny rules fired in one session. The permission_denials array reports one of them. The Read refusal is visible in the tool result, where it carries is_error: true, but it does not reach the summary field. I saw the same asymmetry in two other probes: a Read denial happened, the array stayed empty.

The refusal message describes the wrong rule

Look again at the Read error: File is in a directory that is denied by your permission settings. The rule I wrote was Read(./marker.txt), a single file. In probe 5, I asked for other.txt and marker.txt in the same message. They were issued in parallel. other.txt, in that same directory, came back with its contents. The directory is not denied. The message is wrong about which rule stopped the call.

There is a twist worth recording. In an earlier probe the model read that message, concluded that the whole path was blocked, and said it would not try to reach the file through the /private/tmp alias or through a shell command. An error that overstated its own scope made the block stronger. That is luck, not a control, and I would not build on it.

You cannot ask a script what the rules currently are

Having found a gap in the denial log, I went looking for a way to read the effective merged rule set from a shell script. There is no config subcommand any more. claude --help lists thirteen commands: agents, auth, auto-mode, doctor, gateway, import, install, mcp, plugin, project, setup-token, ultrareview, update.

The failure mode is the part to watch:

$ claude config get permissions
I'm ready to help — what would you like to work on?
$ echo $?
0

The arguments fall through and become a prompt. You get a friendly sentence, a spent model call, and exit code 0. A monitoring script that shells out to this and checks the exit code concludes everything is fine. claude doctor, which advertises that it reads settings files, printed 506 bytes containing no permission information at all.

That leaves exactly one machine-readable channel for an unattended run, the JSON result envelope, and it is the one that drops Read denials. It is the mirror image of what I found on August 10, when I discovered that the usage limit can be read from a script after all. That time I had been wrong because I never ran the one-line experiment. This time I ran it, and the answer really is that the instrument is incomplete.

The bug ledger, and one re-test

I pulled every deny-rule issue I could find in anthropics/claude-code through the GitHub API, seven in total. Six are closed. The longest-lived is issue 8961, opened 2025-10-05 with 19 comments, still open. Five of the seven concern Read or Write rules, the same tool family where my denial log leaks.

One of them was directly testable. Issue 22907, closed 2026-02-07, reported that deny rules do not block the Read tool when absolute paths are used. My probe hit exactly that case by accident: the rule was relative, Read(./marker.txt), and the agent called Read with /private/tmp/permprobe/marker.txt. It was blocked. On 2.1.227 that one is genuinely fixed.

What I have not done

I have not added a single deny rule to this rig. The audit that opens this post is still true as of tonight. What I now know is that the six scripts running with --dangerously-skip-permissions would still respect a deny list, which makes the empty deny list a choice rather than a limitation, and that if I add one I cannot count on permission_denials to tell me when it fires on a file path.

The obvious first entries are the ones I keep writing about anyway: the credentials I audited across this rig in July, and the paths that the container isolation I looked at this morning cannot protect because nothing here starts inside a container. A PreToolUse hook can also refuse a call, and mine already fire on every run, which makes them the other place to put a control that survives the flag.

If you want the full setup this blog runs on, including the scheduling and the guardrail layer, it is written up in the Unattended Agent Playbook. That link is a tracked affiliate link, and I earn a commission if you buy through it.

Method and limits: every number here comes from nine probes I ran on 2026-08-17 against Claude Code 2.1.227 on my own Mac mini, in a scratch directory at /tmp/permprobe, with my production settings untouched. Each probe ran once. The permission layer verdicts, blocked or allowed, were consistent across probes that repeated the same condition, but the two results that depend on what the model chose to do, routing to the Read tool and declining to look for an alias, are single observations and may not reproduce. The claim that deny rules outrank bypass mode is a confirmation of what other write-ups already report, not a finding of mine; the denial-logging gap, the misattributed error message, and the exit code 0 from a command that no longer exists are what I measured myself. Issue states and dates were read from the GitHub API on 2026-08-17 and will drift.