Controlling Claude's Autonomy: Permission Modes and Planning

How much freedom should Claude actually have? That's the real question behind every permission mode this course covers, and it doesn't have one right answer, since it depends on what you're building and how much a mistake would cost you today. Permission modes are the dial. They set how closely you have to watch the task, do, verify loop covered just before this one.

Six permission modes

Figure 12 lays these out side by side. Four live directly in the graphical interface. Two more surface only through a typed command, and both are worth knowing about even if you never touch the main menu where the other four sit.

FIGURE 12 — Six permission modes, from most to least supervised. Four of these sit in the graphical menu; the other two only surface through /permissions, which is easy to miss if you never type it.

Ask before edits, the default. Claude previews a diff and waits. It won't write anything until you approve once, approve for the rest of the session, reject the change, or redirect it entirely. This suits a high-risk codebase where every change deserves a second look. It can also get tedious fast, since frequent prompts interrupt real work, which is exactly why relatively few people in my own workflow still run it as their default setting day to day.

Edit automatically. No prompts here. Claude auto-accepts edits to files that already exist, without asking first. Creating a brand-new file is different, though: that still needs your explicit permission, every time, regardless of how many existing-file edits you've already approved without a second thought.

Don't Ask, reached through the /permissions command. It exposes Allow, Ask, and Deny rules you can set per tool, WebFetch handled one way, Bash handled another, rather than one blanket setting covering every tool at once.

Delegate, built for agent-team leads. In this mode, the lead mostly coordinates and hands off work to other agents rather than doing much hands-on implementation itself, which matters only once you're running more than one agent at a time on the same project.

Bypass Permissions. No prompts at all. Claude just acts, which is fast, and which is also the riskiest setting on this whole list by a wide margin. I've heard a secondhand report, not something I witnessed myself, and I have no source or date for it, of an autonomous coding agent running with broad permissions that misread its own task and ran a destructive command, deleting real data. I'd call this very uncommon. Take the story exactly as flagged: unverified, but still worth knowing about before you flip this particular switch on a project that actually matters to you. Beyond that dramatic worst case, there's a quieter risk too, workspace bloat, meaning unused libraries and abandoned files piling up over a long session, worth clearing out periodically rather than letting them accumulate for months on end.

Plan Mode. Read-only exploration. Claude researches your problem using web tools, reads through your existing files, reasons carefully about a workable approach, and then writes up a plan document for you to review before it ever touches a single file.

FIGURE 13 — Plan Mode: what it actually does. Read-only until you approve, nothing gets written before the gate. In one demonstration, asked to refactor a page from dark mode to light mode, Claude entered Plan Mode, examined the relevant CSS and colour sections, and broke the request into higher-level steps for approval. The interface turned blue while planning, with a stop/pause control able to interrupt execution already in progress.

Why planning first pays off

I use a rule of thumb here, offered as a heuristic rather than any kind of measurement: a minute spent planning can save roughly ten minutes of building later. Figure 14 walks through my own illustrative numbers.

FIGURE 14 — Plan-first vs. no-plan: the presenter's own comparison. These are my own illustrative numbers for one hypothetical build, not a benchmark, the shape of the tradeoff is the takeaway, not the exact minutes. Skip planning, and a bad approach can cost you roughly thirty-five minutes total: building, testing, discovering the mistake, then rebuilding from scratch. Plan first instead, and roughly ten minutes of upfront planning can save about twenty minutes overall, by my own estimate, though the exact build time on that second path isn't stated anywhere in my source material.

I reach for one more analogy here, a construction one: it's cheaper to fix a blueprint than to tear down and rebuild a finished structure once the work is already underway and mistakes have become physically expensive to unwind. That logic generalizes. Planning beforehand, in my own experience, prevents the situation where work has to stop because an important dependency, resource, or material got overlooked.

A full worked example

Here's where it all comes together. My own walkthrough builds something considerably more ambitious than a single web page: a proposal-generation platform, roughly comparable to PandaDoc, with login, AI-assisted proposal writing, client-facing URLs (shareable web addresses), e-signatures, and payment built in.

I didn't write a formal spec by hand. I spoke my requirements into a voice-transcription tool instead, then handed Claude the raw transcript and asked it to organize the result into a structured specification, outcome-oriented throughout, describing what the app should do rather than dictating the technical architecture myself, sentence by sentence. In Plan Mode, Claude asked clarifying questions through an interactive interface: which frontend framework, how robust the e-signature needed to be, fixed or variable pricing, whether Supabase should just handle login or the whole database too. I mostly picked the recommended option each time rather than deciding every detail from scratch on my own.

FIGURE 15 — AskUserQuestion planning interaction. One of four questions Claude asked, instead of requiring every decision up front.

Rather than asking Claude to invent a proposal layout from nothing, I supplied an existing nine-page proposal document as the actual design reference, and gave one more instruction on top of it: keep the rest of the app simple, clean, and Apple-like. Claude delegated part of the planning. A subagent handled it, and researched the named reference product on its own. The resulting plan named a specific technical stack, Next.js, Supabase, Tailwind, Stripe, among others, worth remembering as a snapshot of one moment, not a permanent recommendation, since stacks like this shift constantly as tools rise and fall out of favor. It also mapped the supplied proposal into concrete sections and sketched out a first pass at the database schema.

I reviewed the intended user flow before approving anything: sign in, reach a dashboard, start a new proposal, fill in a brief description and pricing, generate content through the model, then get a public URL to send straight to a client. Once I accepted the plan, I switched from Plan Mode to Bypass Permissions, since I didn't want to approve every single action every few seconds while real implementation was actually happening in front of me. While Claude built, I didn't just sit and watch. I set up Supabase and created a Stripe test environment in parallel, using the waiting time for something else that also needed doing anyway.

My argument for the whole approach, restated plainly at the end: a completed plan improves your odds of a correct first implementation, and it saves tokens too, since Claude isn't exploring competing approaches while simultaneously trying to write working code at the same time. Think of it like onboarding. A checklist beats a vague assignment. Plan, start the build, let Claude work, spend the waiting time on something else useful, then come back when it actually needs your attention again.

Finishing the build, then shipping it safely

The build wasn't actually finished yet. It still needed real credentials. Claude listed what remained: a Supabase project URL, an Anthropic API key, a database migration to run, a Stripe webhook to configure, and a deployment to Netlify still to do. So I tested locally first, working through each integration one at a time and confirming the whole flow actually worked before I shipped anything at all.

Local testing found two real problems. Signup showed an unfriendly red "email not confirmed" error, so I asked Claude to show a plain "check your inbox" message instead. The confirmation email itself never arrived during the demo, so I found a Supabase setting and turned confirmation off, strictly for local testing. Generating a proposal also left me staring at a bare loading spinner with no sense of whether anything was happening, so I asked Claude for clearer progress feedback instead of guessing, since neither I nor a future user should have to wonder whether the request actually went through.

A full design review followed the same pattern: instruct, don't edit by hand. Narrow some text blocks, widen others. Line up a set of numbered labels that weren't aligning cleanly. Shorten a confetti animation that ran too long. Swap an email-based next step for a direct calendar-booking link. I also noticed the layout stretched too wide on my own desktop monitor, even though it worked fine on mobile, so I centred the whole proposal at one fixed width. Then I confirmed the functional path worked end to end: signing, a sandboxed Stripe payment, a "payment received" confirmation, and a client-facing proposal URL that still loaded from a separate, logged-out browser tab.

Before deploying, here's one workflow habit worth keeping: when Claude suggests manual steps, it's often worth checking whether Claude can just do them. For the deployment itself, though, I stayed hands-on: I imported the repository into Netlify, confirmed the build settings, and published to a public URL myself. I then copied the local .env file's values into production and configured the Stripe webhook, also by hand. Claude touched none of that. Its role came after, diagnosing a build failure (the Stripe and Anthropic clients were initializing eagerly rather than lazily) and committing and pushing the fix so Netlify could rebuild. A separate written reference in my source material covers deploying the same app to Vercel instead. One detail generalizes past its exact names: when a Next.js app lives in a subfolder rather than the repo root, the deploy platform's root-directory setting has to point there explicitly. A few environment variables also can't be finalized until the platform assigns a domain, which means one redeploy after they're set.

Once the app was live, I reflected on how little hands-on coding the project actually took. The plan did most of the work up front. Most of the execution ran on its own. That left me with what I call the real job: deciding what to build, supplying business context, reviewing the result, and steering Claude when something needed adjusting.

Before you ship it

That reflection comes with a warning attached. A working application is not the same thing as a secure one, and I'm direct about drawing that line before anyone else gets anywhere near what Claude just built for me.

FIGURE 16 — Before you ship it. Working does not mean production-secure, three checks before anyone else sees it.

Public applications get probed the moment they're reachable. Don't assume Claude Code caught every issue on its own. My first precaution is minor by itself: skip an obvious, guessable URL for an experimental app. Scanners crawl domains constantly, and a short URL is easier to stumble onto by accident. My second precaution matters more. Don't charge customers for an app like this without a developer reviewing authentication first, real usernames, passwords, and payment records are what's at stake once you do. I now keep these fast-built apps for internal or client use, rather than releasing them broadly. My reason: security problems I say I've seen in other quickly deployed AI-agent projects. I give no source or date for that, so take it as my own experience, not a documented case. I put the whole build at roughly fifteen to twenty minutes of my own active time. Something that fast, handling real credentials and real payments, is exactly why security stops being optional the moment anyone besides you uses it.

Try this with AI "Here's a short description of an app I just built: [describe it]. Based on the two checks above, guessable URLs and reviewed authentication, what else would you flag before I let a real customer use it?" Don't paste real credentials, API keys, or customer data into this prompt, only a description of the app.