Lesson 18: Permissions & Trust

Day 18 of 50 · ~7 min read · Phase 3: Customization

The Opening Question

You've been working with Claude Code for a while now. Each time Claude wants to run a command, edit a file, or create a pull request, it stops and asks for your permission.

This is intentional. But it raises a question: How much autonomy should you actually give an AI agent?

Is it better to be asked about every single action, or does that get in the way? And if you loosen the guardrails, where do you draw the line?

Discovery

Let's think through the tradeoffs.

Question 1: Why does Claude ask permission in the first place?

You're the person responsible for your codebase. If Claude deleted files, pushed breaking changes to production, or exposed secrets, that would be on you.

But here's the deeper question: What kinds of things should require permission, and why?

Pause and think: If Claude Code was completely silent and just did everything, what could go wrong?

There are a few categories of risk:

Irreversible actions — pushing to git, deleting files, shipping to production. If Claude makes a mistake here, you can't easily undo it.

Sensitive data exposure — reading environment files, API keys, or private configuration. Claude might accidentally include these in logs or commits.

Time-consuming operations — running a full test suite, building Docker images, or long-running commands. You should know this is happening.

Security decisions — granting permissions, changing access controls, or modifying who can access a resource.

These are worth asking about. But reading a file? Searching code? Running a quick test? Those are lower-risk and might not need permission every time.

Question 2: What are the different permission modes Claude Code supports?

Claude Code has a few different ways to handle permissions. Let's explore them:

Ask every time (default). Claude stops and asks before any action that might have side effects. This is safe but can be slow if you're doing a lot of work.

Plan mode. Claude proposes a full plan first (which files it'll change, which commands it'll run), and you approve the whole plan at once. Then Claude executes without asking about individual steps. Faster than asking every time, but you need to carefully review the plan.

Accept edits automatically. If Claude is making code changes that pass your tests, automatically approve them. This assumes Claude's checks (tests, linting, etc.) are good enough to catch most mistakes.

Bypass for specific tools. You might say: "Always let Claude run tests without asking, but ask about git push." This lets you customize which actions need permission.

Trust specific commands. You might allowlist certain Bash commands — like npm test or ls — that Claude can run without asking. But block dangerous ones like rm -rf.

The question is: which of these matches your workflow and your risk tolerance?

Pause and think: Do you trust Claude's test checks? Do you mostly work on feature branches before shipping to main? Are you the only person working on this codebase?

Your answers determine what permissions make sense.

Question 3: How do you configure permissions in Claude Code?

This brings us to the practical part: actually setting your permission preferences.

Claude Code stores settings in .claude/settings.json — a file in your project root. This is where you define how strict or loose the permissions should be.

Here's what a settings file might look like:

{
  "permissions": {
    "mode": "plan",
    "autoAcceptEdits": {
      "enabled": true,
      "requirePassingTests": true
    },
    "bypassTools": {
      "allowed": ["bash:npm test", "bash:git status"],
      "blocked": ["bash:rm", "bash:git push origin main"]
    }
  }
}

This says:

• Use plan mode (review the plan, then Claude acts without asking about each step)
• Auto-accept edits if the tests pass
• Allow Claude to run npm test and git status silently
• Block any rm command and any push to main (even with a plan)

The key insight: These settings are about matching Claude's behavior to your workflow, not about trusting or distrusting Claude. They're about what makes sense for your project and your team.

Question 4: What's the tradeoff between speed and safety?

Let's be honest about what you're optimizing for.

If you set permissions to "ask every time," you're optimizing for maximum control and visibility. You'll catch any mistake Claude makes. But if Claude is doing a lot of work — making 50 edits across 10 files, running multiple test suites, checking things — you'll be clicking "approve" dozens of times.

If you set permissions to "plan mode" or "auto-accept edits," you're optimizing for speed. Claude can iterate faster, fix issues without interruption, and get to the finish line quicker. But if Claude makes a mistake, you might not catch it until later.

The sweet spot usually depends on context:

Tight permissions when:

• You're exploring something unfamiliar and want to watch every step
• The code is critical (payment processing, authentication, etc.)
• You're working on a shared codebase where mistakes affect others
• Claude seems confused or is making mistakes

Loose permissions when:

• You're in a feature branch that no one else is using
• Claude has successfully completed similar tasks before
• You have good test coverage that catches bugs automatically
• You're trying to move fast (hackathon, time-sensitive deadline)

Pause and think: Where do you fall on this spectrum? What's your natural instinct?

The Insight

Here's the core idea:

Permissions aren't a binary choice between "trust Claude completely" and "ask about everything." They're a spectrum that you can configure based on your project's needs, your codebase's criticality, and how confident you feel about Claude's work. The more you understand what permissions exist and why they exist, the better you can tune them to your workflow.

The mental model: Permissions in Claude Code work like access controls in real life. A junior developer on the team might need closer supervision (ask every time). A senior developer you've worked with for years can make changes more freely (auto-approve). The level of oversight scales with experience and risk. You set the level that makes sense.

Try It

Let's configure your first permission settings.

1. In your project root, check if .claude/settings.json exists:

   cat .claude/settings.json
   

   If not, create it.

2. Start with plan mode. This is a good middle ground:

   {
     "permissions": {
       "mode": "plan"
     }
   }
   

   Save the file.

3. Run a coding task in Claude Code:

   claude "Add a simple logging utility to the project"
   

   Watch how Claude proposes a full plan first, then asks for your approval on the entire plan rather than each individual step.

4. Experiment: Once you're comfortable, try adding an auto-accept rule for a specific tool, like npm test:

   {
     "permissions": {
       "mode": "plan",
       "bypassTools": {
         "allowed": ["bash:npm test"]
       }
     }
   }
   

5. Test it with another task and see how Claude now runs tests without asking.

Key Concepts Introduced

Bridge to Lesson 19

You now understand how to control Claude's permissions. But permissions are one-dimensional — they say "yes" or "no" to actions.

What if you could teach Claude new verbs? What if you could say "format the code" and Claude would know exactly what that means for your project?

Tomorrow's question: What if your most common workflows could be automated as commands?

We'll explore slash commands — built-in shortcuts and custom ones you create to make repetitive workflows instant.

← Back to Curriculum · Lesson 19 →