Permissions and privacy

Chapter 3 left two things out of the vault on purpose, a gate code and a supplier’s portal login. Suppose an invented note, “Supplier portal login”, had ended up in a Private folder anyway. The figure lists five things the agent might try and five ways the firm might have protected the note. Pick a protection and see what it stops; four of the attempts are reads of the note, and one is an edit to a rule. Every verdict assumes a session where edits and shell commands are already approved, so no prompt stands in the way.

My viewThe idea of this chapter: an agent can only leak what it can read, so the question is what stands between the agent and the file. The answers differ in kind. One is a request, one is a rule a program checks, one is a script you write, one is a boundary the operating system holds, and one is the file not being there.

The first is the note. Claude Code’s docs say its memory files are loaded at the start of every session and that Claude treats them as context, not enforced configuration. To block an action whatever Claude decides, the same page points to a PreToolUse hook, and it says a hook runs at a fixed point and applies regardless of what Claude decides. The permissions page puts it the same way: permission rules are enforced by Claude Code, not by the model.

My viewTo my eye, then, a note that says “never repeat a login” asks; it does not stop anything. That is the rest of this chapter in one line.

The second is a permission rule. The docs describe allow, ask and deny rules, checked deny first, then ask, then allow. A deny rule on a path such as the private folder blocks Claude’s built-in file tools from reading it, and the docs say it also covers file commands Claude Code recognises in a shell command, like cat. They say it does not cover a command that reads files without naming them, such as a recursive search from the folder that holds the note, or a script that opens files itself. For the search tools the docs say Claude makes a best-effort attempt to apply read rules. A read-only command such as cat or grep runs without a prompt in every mode; in Manual mode an edit, and most other shell commands, prompt.

An ask rule prompts for confirmation every time, and the docs say edit rules apply to all the built-in tools that edit files. Chapter 3 sent writes to rules, decisions, procedures to a person.

My viewTo my eye, a rule per folder is the same reviewer written into the agent’s settings, where the program enforces it instead of the figure.

The third is a hook. The hooks reference describes hooks as handlers that run at points in Claude Code’s lifecycle and are given JSON about the event; for a shell command, that includes the command to be run. A PreToolUse hook runs before a tool call and can block it; its exit code 2 blocks the call, and a hook that returns nothing has made no decision, so the normal permission flow carries on. The same page says a hook that times out, crashes, cannot start or prints invalid JSON does not block unless you set onFailure to block, so a stalled or broken hook is not a gate. The permissions page says a hook cannot override a deny rule, and that a hook is the way to look at a whole command with your own logic. It also says an installed mod can approve a call a deny rule refuses, unless managed settings or a Team or Enterprise login apply.

The fourth is the sandbox. The docs describe it as an operating-system boundary around shell commands and the processes they start, which holds whatever command the model chose to run. They say it does not cover Claude’s file tools, which follow permission rules instead, and that Read and Edit deny rules are merged into the sandbox’s configuration; the page does not spell out how a path in a rule becomes a sandbox setting. It is off by default. If it cannot start, Claude Code runs commands without it unless failIfUnavailable is set. And when a command fails inside it, Claude can retry that command outside the sandbox, which a matching allow rule approves, unless allowUnsandboxedCommands is false. Commands that match excludedCommands run outside it too. The docs’ own limitations section says sandboxing reduces risk but is not a complete isolation boundary. The permissions page calls the two layers complementary.

My viewThe fifth protection is of a different kind. If the note is not in the vault, there is nothing for any of the others to guard. It protects the login, not the rules around it.

My viewThe figure reads from those pages, and the sandbox verdicts hold only for the setup shown: allowUnsandboxedCommands false, with the sandbox started. Reading the tallies: with the permission rule alone, two of four reads of the note are stopped; with the sandbox and the retry switched off, four; with the note not there, four. The verdicts are written by me from the docs, and the check on them tests that each is consistent with its setup, not that Claude Code behaves that way.

My viewChapter 3 says a secret does not belong in the vault: anything an agent can read it can repeat. The rules here are partial, and the docs say so, which is another reason to keep the secret out.

My viewThis chapter draws one agent’s rules by folder. How several agents in one graph each get their own is for the chapter about the vault inside a graph, which is not written yet, so this page does not claim to settle it. The verdicts follow the pages I read on the date shown, and those pages change with the program, so test a rule yourself before you rely on it, with a file that holds nothing real. Nothing in the figure runs a rule or calls a model; the answers are scripted from the docs.