Ch.3: Claude Code Permissions: The Trust Dial

0:00 Welcome to Learning Podcasts. Claude Code: The Permission Model. Claude Code can run R-M dash R-F. It can drop your database, rewrite git history, and push to main. That is not a bug. That is the whole reason this chapter exists. Recorded in April 2026. Claude Code ships weekly, so check the docs for exact names and switches. The durable lesson is simple: permissions decide how much trust this agent gets today. So think about permissions as a trust dial, not a single safety switch. At one end, Claude asks before meaningful action.

0:34 In the middle, file edits flow but shell commands still get a prompt, or a classifier handles the routine calls. At the locked-down end, anything you did not pre-approve is denied. At the loose end, prompts are skipped because you put the agent somewhere disposable. So the question is not, is Claude Code safe. Right. The question is, what boundary fits this task, this repo, and this machine. The permission system sits in front of tool use. Reading files, editing files, running Bash, fetching the web, talking to MCP servers, spawning subagents.

1:11 They are different kinds of action. They do not carry the same risk. Reading a source file is not the same thing as a shell command that touches your database. Exactly. Permissions turn that difference into policy. Some actions can proceed. Some should ask. Some should never happen. Default mode is the cautious starting point. Claude can explore. But when it wants to edit a file or run a command that needs approval, you see a prompt, and you decide whether this one action is okay. Slower, but it builds the habit of reading what the agent is about to do.

1:45 And that habit is the point. Default is right for a new codebase, a sensitive repo, or a task where you do not trust the direction yet. Accept edits removes one common source of friction. File changes inside the working area land without asking every time, so Claude can refactor, adjust tests, and fix formatting without stopping at each replacement. But shell commands are still different. Yes. You still review commands that do more than ordinary file work. The tradeoff is clean. Let the text changes flow, then inspect them with your editor or git diff after the fact.

2:20 This is the mode most people actually live in. Plan mode is the opposite habit. Claude researches and proposes before changing source files. It can inspect the repo and build an approach, but it is not supposed to edit your code as part of that planning pass. Permission prompts still apply for commands the plan needs to run. So that is the mode for, before you touch anything, tell me what you think is happening. Exactly. We go deeper on plan mode in the next chapter. The short version is, it prevents the most common beginner mistake: letting the agent implement before it understands.

2:56 Auto mode tries to reduce prompts without removing judgment. A separate classifier reviews actions before they run. Ordinary work that matches your request can proceed. Risky work, like destructive file changes or actions that look driven by hostile content, should be blocked or escalated to you. A classifier deciding what is safe in real time sounds like the kind of thing that breaks at the worst time. When it gets it wrong, do you even know. Fair concern. Auto is a research preview, and eligibility depends on plan, admin settings, model, and provider.

3:30 The honest framing is, when the classifier is uncertain, the prompt comes back. So the failure mode is more interruption, not silent action. The mode is a middle path, not a guarantee. Don't ask sounds permissive, but it is actually a locked-down automation mode. Claude does not ask whether an unapproved tool call is okay. It denies it. So that is for CI. Exactly. In a pipeline you do not want a prompt waiting for a human. You want a short allowlist: run tests, inspect files, maybe write a report.

4:02 Everything else is denied by default. We come back to this much later in the series. Bypass permissions is the dangerous-looking one because it is dangerous on the wrong machine. It skips prompts for most actions. Current Claude Code still protects certain sensitive directories, but the whole point of this mode is that you are no longer reviewing each step. Plenty of teams just refuse to use bypass at all on principle. Are they wrong. They are not wrong. On a personal laptop with cached cloud credentials and a real repo, the principled refusal is the right call.

4:35 The mode earns its place only when the workspace has no production access, no valuable credentials, and nothing you cannot recreate. A container, a devcontainer, a disposable virtual machine. Outside that context, the principled position holds. You can switch interactive modes during a session, commonly with shift tab, and you can inspect or edit permission rules with slash permissions. You can start Claude with a specific permission mode from the command line, or set a default in settings dot jay-son with default mode.

5:06 So the mode is operational. It is not your identity as a cautious or aggressive developer. Exactly. Use default for unfamiliar work. Use accept edits when the task is local and clear. Use plan when the risk is misunderstanding the problem. Modes set the broad posture. Rules handle the details. There are three rule types: allow, ask, and deny. Allow means go ahead. Ask means interrupt me. Deny means block it. And that is where permissions become practical. If you always approve npm test, allow it.

5:44 If reading dot env should never happen, deny it. Rules live in settings, not in clawd dot em dee. Clawd dot em dee tells the agent what you want it to know about the project. Settings tell the agent what it is allowed to do. A later chapter has the clawd dot em dee story. Precedence is the part to memorize. Deny, then ask, then allow. The first matching rule wins. Deny always wins over a broad allow. So you can write a generous allow and carve the scary parts out with deny. Exactly. You might allow normal test commands, then deny anything that touches secrets.

6:19 You might allow read-only project inspection, then ask before web requests to unknown domains. The order lets you be broad without being blind. A rule like Bash open paren npm run space star close paren can cover a family of test or build commands. A rule like Read open paren dot slash dot env close paren can block one sensitive file. A rule like web fetch open paren domain colon example dot com close paren can control external fetches by domain. The patterns are powerful, but they are also sharp.

6:53 Yes. Broad Bash patterns deserve respect. A wrapper command can be much broader than it looks. If a command reaches production, changes cloud resources, or sends data outside the repo, make the rule specific. Permissions live in settings, and settings have layers. Managed settings let an organization enforce rules developers cannot override. Project settings can be checked into the repo for the team. User settings apply across all your projects. Local project settings hold personal preferences that should not be committed.

7:27 So a company can say, nobody gets bypass mode on production laptops. Right. And an individual developer can still say, in this repo, ask me before push, always allow the formatter, and never read secrets. Sandboxing is the lower fence underneath permissions. On macOS, Claude Code uses Seatbelt. On Linux and double-you-ess-el two, it uses bubblewrap. It can restrict filesystem writes and route network access through a proxy, applied at the operating-system level. If my permissions are correct, why do I need a sandbox underneath.

8:01 Is that not redundant. Different layer, different problem. Permissions decide what Claude is allowed to try. Sandboxing decides what the spawned subprocess can reach. A rule that allows npm test still lets npm test spawn child processes that might write outside the workspace or open network connections. Sandboxing follows those subprocesses. Permissions do not. They complement each other; one without the other leaves a real gap. A practical starting point is boring on purpose. Start in default mode on unfamiliar work.

8:36 Add allow rules for commands you approve constantly: tests, formatters, local type checks. Add deny rules for secrets, credential files, production deploys, and destructive paths. Use accept edits once you trust the task shape. Use plan mode before big changes. Turn on sandboxing when your platform supports it. And watch what you approve repeatedly. Yes. Repetition is feedback. Promote boring approvals into allow rules. Turn scary moments into deny rules. The permission model is not there to make Claude Code timid.

9:11 It is there to make trust explicit. Your comfort level today is allowed to be different from your comfort level tomorrow. Next chapter, the safest productivity trick in the tool: plan first, execute second. Thanks for listening to Learning Podcasts.