Claude Code Claude CodeSafety

Plan mode & permissions in Claude Code

Plan mode makes Claude Code read and propose a plan without changing anything, so you approve the approach before it acts. Permissions control what the agent is allowed to do on its own: by default it asks before actions that change files or run commands, and you widen that deliberately. Together they are the approval gate, built into the tool.

Overview

Early on, I let Claude Code just go on a cleanup task, and it went. It made a sweeping set of changes across a batch of files, all technically what I had asked for, and none of it what I actually wanted. Untangling it took longer than the task would have by hand. The agent was not wrong. I had skipped the step where I look before it leaps.

Plan mode is that step, made a feature. It makes Claude Code read the situation and lay out a plan without changing a thing, so you approve the approach before it acts. Permissions are the companion: what it is allowed to do on its own.

The scary part of an agent is not its thinking, it is that it can act on its thinking before you have seen it. These two settings close exactly that gap. Here is how to use them.

Plan mode: approve the approach first

Plan mode: approve the approach first

In plan mode, Claude Code reads what it needs and lays out a plan, the steps it intends to take, without changing anything yet. You see the approach, adjust it if it is off, and only then let it execute. It turns the agent from something that acts and reports into something that proposes and waits.

For anything non-trivial, this is the right default, and my sweeping-cleanup scar is why. It is cheap to read a plan and expensive to undo a wrong action, so make the cheap check the habit.

The value is that it moves the cheapest moment to catch a mistake to the front. A wrong approach caught in a plan costs you a sentence of correction. The same wrong approach caught after Claude has rewritten six files costs you an untangling. Plan mode is you buying certainty about the direction before you pay for the distance.

Plan mode: read-only until you say go
01PlanClaude reads and proposes, changes nothing
02You reviewthe plan, before any action
03Approveaccept it or adjust it
04Executeit acts, inside your permissions
Plan mode is the approval gate built into the tool: nothing changes until you have seen the plan and said yes.
💡

TipUse plan mode any time the task touches more than one file or you are not certain what the agent will do. Reading a plan costs thirty seconds; undoing a bad run costs your afternoon.

How to read a plan well

How to read a plan well

A plan is only a guardrail if you actually read it, so read it for intent, not just steps. The question is not does each step look reasonable, it is did it understand what I am trying to do. A plan that is competent but aimed at the wrong goal is the dangerous one, because it will execute flawlessly in the wrong direction.

Look for the assumption you did not state. Plans reveal what Claude inferred: which file it thinks is the source of truth, what it assumes done means, whether it caught the edge case. If the plan assumes something wrong, that is your cue to correct the assumption now, in one line, instead of discovering it in the output later.

💡

TipRead the plan for whether it understood the goal, not just whether the steps look fine. A flawless plan aimed at the wrong target is the expensive kind.

Permissions: what it can do on its own

Permissions: what it can do on its own

Permissions govern which actions Claude Code takes without stopping to ask. Out of the box it asks before it edits files or runs commands, so nothing irreversible happens by surprise. You can allow specific safe actions to run without prompts once you trust them, and deny others outright.

The goal is not maximum autonomy, it is the right autonomy. Let the boring, safe, reversible steps run unattended, and keep a hand on the ones that matter. An agent that never asks is fast right up until the day it is fast in the wrong direction.

Permissions and plan mode answer two different questions. Plan mode asks did we agree on the approach. Permissions ask what is this allowed to do without checking. You want both, because an approved plan can still contain a step you would rather see before it runs, and permissions are the net that catches those regardless of the plan.

Widen it deliberately

Widen it deliberately

It is tempting to turn off the prompts to move faster, and that is exactly how an agent does something you did not want. Widen permissions for scoped, reversible actions you have watched it perform correctly, and keep the gate on anything that writes to a live system. Loosen on purpose, one step at a time.

The rule I hold: I grant standing permission only after I have seen the action go right a few times, and never for anything I could not comfortably undo. Trust is earned per action, not granted wholesale.

The right direction to move is from tight to loose, guided by evidence. Start with the agent asking about most actions, watch which categories consistently go fine, and widen those. Widening by observation means your trust and the agent's freedom grow together, instead of granting broad latitude on faith and clawing it back after a scare.

💡

TipNever blanket-approve to save clicks. Grant standing permission action by action, only for the reversible ones you have already watched succeed.

How they work together

How they work together

Plan mode and permissions are two layers of the same idea. Plan mode governs the approach, do I agree with the plan before anything happens. Permissions govern the execution, which individual actions may run without me. Use both and you get an agent that proposes a plan you sign off on, then executes it within limits you set.

That combination is what makes an agent both fast and safe. The plan keeps the strategy under your control; the permissions keep the tactics inside a fence. Neither alone is enough for work that touches anything real.

In combination they give you a two-stage checkpoint. Plan mode is the design review: agree on the approach before anything happens. Permissions are the runtime guard: even inside an approved plan, the actions that can hurt still pause for you. Design review plus runtime guard is exactly how you would want a capable but new team member to operate, and it is how you should run the agent.

When to skip plan mode

When to skip plan mode

Plan mode is not free, it adds a step, and for the wrong tasks that step is friction with no payoff. Read-only work does not need it: asking Claude to summarize a script, explain what a file does, or pull a number changes nothing, so there is no approach to approve. Turn it on for changes, not for questions.

The judgment call is about blast radius. Anything that edits real files, rewrites logic, or touches your data wants a plan first. Anything that only reads and reports can run straight through. Match the ceremony to the risk and plan mode stays a tool you value rather than a toll you resent.

  • Use plan mode for: editing files, rewriting logic, anything that changes state.
  • Skip it for: read-only asks like summarizing, explaining, or pulling a number.
  • The test: is there an approach to approve, or just a question to answer?
Plan mode is how you learn to delegate

Plan mode is how you learn to delegate

The deeper thing plan mode gives you is a way to build trust on purpose. The first few times you hand a category of work to the agent, run it in plan mode and read the plan closely. You are not just approving a task, you are learning how it thinks about that kind of work, where its judgment is sound and where it needs a tighter brief. That is calibration you cannot get any other way.

After enough good plans in a category, you have earned the right to loosen up: skip plan mode for that kind of work, widen the permissions, let it run. Plan mode is the training wheels that come off one category at a time. The operators who trust the agent most are not the reckless ones, they are the ones who watched enough plans to know exactly when watching stopped being necessary.

Where people get burned

Where people get burned

The classic mistake is turning everything to auto-accept early, chasing speed, and then discovering the cost the first time the agent confidently does the wrong thing to a real file or system. Speed you cannot trust is not speed, it is a bet.

The opposite mistake is over-gating to the point that you approve every trivial read and the agent is no faster than doing it yourself. The art is in the middle: read plans for real work, auto-allow the safe stuff, gate the irreversible. Get that balance and the agent earns its autonomy.

The quiet failure is approving plans on autopilot. Plan mode only protects you if you read the plan, so rubber-stamping it is worse than not using it, because it gives you the feeling of a checkpoint with none of the protection. If you catch yourself approving without reading, either slow down and read, or admit the task was safe enough that you did not need plan mode for it in the first place.

💡

TipIf you are approving harmless reads all day, loosen those. If you are auto-accepting live writes, tighten those. The gate belongs on the irreversible, not the trivial.

The GTM guardrail

The GTM guardrail

This is the same approve-then-act pattern behind the site's automations: the agent reads and proposes, a human approves, and only approved actions touch anything live. Plan mode plus tight permissions is how you get the speed of an agent without handing it the keys to your CRM or your ad account.

Build the habit early, while the stakes are small. It is far easier to loosen a cautious setup once you trust it than to recover from a fast, wrong one that already emailed a customer or changed a budget.

So before you let an agent loose on anything that touches a live system, ask: have I seen the plan, and is the write behind a gate? What is the one action you would never want it to take without you?

💡

TipFor any workflow that writes to a live system, keep plan mode on and the write behind an explicit approval. The one-line yes is the cheapest insurance you will ever buy.

How to set it up

How to set it up

Turn on plan mode before a big change

Plan mode makes Claude Code read and think, then hand you a plan, without touching a single file. Toggle it, then give it the job.

claude
$# press shift+tab to cycle into plan mode
plan mode on -- Claude will propose, not act
$Rewrite how we score leads in score.py so demo requests weigh more than newsletter signups.
Plan: 1) read score.py 2) adjust weights 3) add a test 4) show you the diff. Approve?
$

Read the plan, then approve or redirect

You get the approach before any work happens, which is where you catch the misunderstanding cheaply. If the plan is right, approve it and it executes. If it misread the goal, correct it now, before it has written anything.

Set permissions to match your trust

By default the agent asks before actions that change things. As you learn which jobs are safe, widen what it can do on its own, and keep the risky reach (deleting, sending, pushing) behind an explicit yes.

💡

TipPlan mode for anything that edits real files or logic. Skip it for read-only asks like 'summarize what this script does'.

FAQ

Frequently asked questions

What is plan mode in Claude Code?

A mode where Claude Code reads and proposes a plan without changing anything, so you approve the approach before it executes. It turns the agent from act-then-report into propose-then-wait, which is the right default for non-trivial work.

How do permissions work in Claude Code?

They control what the agent can do without asking. By default it asks before editing files or running commands; you can allow specific trusted actions to run without prompts and deny others. It is how you tune autonomy safely.

Is it safe to let Claude Code act on its own?

With guardrails, yes. Keep plan mode on for non-trivial work and permissions tight, widening them only for scoped, reversible actions you have verified. Keep the gate on anything that writes to a live system.

Should I turn off the permission prompts?

Only deliberately, and only for safe, reversible actions you have watched perform correctly. Turning off prompts wholesale is how an agent does something you did not intend to a real file or system.

What is the difference between plan mode and permissions?

Plan mode governs the approach, you approve the plan before anything happens. Permissions govern execution, which individual actions run without asking. Use both: approve the plan, then let it act within limits.

When should I use plan mode?

Any time the task touches more than one file or you are unsure what the agent will do. Reading a plan is cheap; undoing a wrong multi-file change is not. For live-system work, keep it on by default.

How does this apply to GTM automations?

It is the approve-then-act pattern: the agent proposes, a human approves, and only approved actions touch live systems like your CRM or ad account. Plan mode plus tight permissions gives you an agent's speed without the keys.

What is the biggest permissions mistake?

Auto-accepting everything early to save clicks, then paying for it the first time the agent confidently does the wrong thing. Gate the irreversible, auto-allow the trivial, and earn autonomy action by action.

Sources

Sources & further reading

Claude ships fast. This page was last reviewed Aug 22, 2026; verify time-sensitive details against the official docs above before relying on them.

Get the AI-for-GTM playbook in your inbox

New Claude guides, use cases, and prompts every couple of weeks.

Subscribe →