Notes: Decide What Claude Can Do on Its Own

In This Section, You Will Master:

• The six permission modes, and the single question that puts four of them in order
• The difference between Claude writing and Claude running, and why it decides your mode
• Writing permission rules into a file, so you answer a question once instead of every time
• The three reasons a correctly written rule goes quiet, and which one to check first
• Handing a whole job over after reading the plan, and walking away from it

How to Use These Notes:

These notes are designed as quick-reference companions to your video learning.

• Use them to review key concepts after watching lectures
• Reference them when you need a quick reminder of frameworks and tools
• 🎯 Core Concepts = Essential terms and frameworks
• 🚀 Actionable Items = Practical implementation steps

The Growth Payoff:

You stop answering permission prompts in the middle of something and start deciding, in advance and in writing, what Claude may do on its own. That decision then holds in every session, through every door into the tool, on every machine you open the project on.

---

Lecture: Before you decide what it may do on its own (Your Permission Defaults)

More than once you said yes to a prompt without weighing it, because weighing it would have interrupted what you were doing.

🎯 Core Concepts:

• The question is not whether that was wrong. It is what you would have said if you had decided in advance, sitting somewhere calm with nothing running
• What this tool can reach is exactly what you can reach, sitting where you are sitting right now
• Four things get settled here: a default you can defend, rules that stop the repeat questions, a diagnosis for when a rule is ignored, and switching posture mid-job
• None of it is about how much you trust Claude. It is about where you want to spend your own attention

---

Lecture: When does Claude ask you first, and when doesn't it? (The 6 Modes)

Every mode comes down to one question: how much does Claude check with you before it acts.

🎯 Core Concepts:

• Manual, the careful default, asks before every file change and every command
• Accept-edits changes files without stopping, plus a short list of housekeeping commands. Plan thinks through the approach before touching anything. Auto runs commands on its own and stops only for actions carrying real weight
• Dont-ask never waits and exists for scripts running with nobody in the room. Bypass-permissions turns the ordinary checks off, and is not even in the mode list until you switch it on yourself
• The real danger is a chain of steps, where step two quietly assumes step one worked
• Claude cannot always tell your instructions from instructions hidden inside a file or a page it reads, so turning off the guardrails trusts everything Claude reads
• Approval fatigue is real. When the answer is almost always yes, the prompt has stopped being a check

---

Lecture: How much freedom am I giving it? (Putting the Modes in Order)

Four of the six modes answer the same question, so they sit on one line. The break in that line is the whole lecture.

🎯 Core Concepts:

• The line runs manual, accept-edits, auto, bypass, from most checking to none at all
• Everything left of the break is Claude writing. Everything right of it is Claude running
• A file Claude wrote is sitting there for you to read, and your saved history puts it back on one command. A command Claude ran leaves no trace in that comparison anywhere
• So the question at the start of a job is not how much you trust Claude. It is whether the risk here is writing or running
• Plan does not sit on that line at all. It is a stage that comes before you pick one
• Accept-edits will delete a file inside your folder without asking, because that counts as housekeeping. That is exactly why the left side is only safe on work you have already saved

---

Lecture: Why does it keep asking after Always Allow? (Why Some Approvals Stick)

You clicked Always allow twice yesterday. Today one of them holds and the other asks again.

🎯 Core Concepts:

• An approval on a file change lasts until the session ends. An approval on a command is saved permanently, for that repository and that command
• The saved ones get written into a small file at the top of your repository, inside a folder called .claude
• Every rule is allow, ask or deny, checked in that order: deny first, then ask, then allow. The first match decides, and a more specific rule does not jump the queue
• Always allow only ever writes an allow, which is the last thing checked, so any ask rule above it wins every time
• If a file change is asking again, nothing was saved, nothing is broken, and it will ask again tomorrow too

---

Lecture: How do I decide once instead of every time? (Your Own Permission Rules)

There is a file in your project full of rules you never wrote, added a line at a time every time you clicked. Your own rules go somewhere you choose.

🎯 Core Concepts:

• Two places are enough to start: a .claude folder in your home directory for rules you want everywhere, and one inside the project for that project. Both files are called settings.json
• The three lists are nowhere near equal. An allow you regret takes about ten seconds to narrow or delete, an ask you regret prompts you forever, and a deny you regret cannot be overridden by anything, from anywhere
• A line earns its place by changing what happens. Most configs found online are full of lines that change nothing, because Claude already runs those without asking
• Only write a rule if you can name the thing exactly, because a vague rule either never fires or fires on something you never meant, and neither failure announces itself
• Reads inside your working folder never prompt, which is why an empty deny list is not a decision you get to make about your keys file
• Permission rules from every level merge into one pile rather than replacing each other

🚀 Actionable Items:

• Write the rule down the fifth time you approve the same harmless thing in one afternoon. Repetition is the signal that it belongs in a file

---

Lecture: Why isn't my settings file working? (Three Places to Look)

You write the rule, spell it correctly, save the file, and Claude asks you anyway. Three things decide whether your rule applies, and not one of them is the text of the rule.

🎯 Core Concepts:

• Where you started Claude. That folder is your working directory, and reading needs no approval inside it. Step outside and the same read stops and asks you
• Whether you accepted the workspace trust dialog. Until you do, that project's allow rules get read and not applied
• What the rule was aimed at. A permission that arrived attached to one particular request covers only the turn that used it
• The diagnosis worth keeping: asking before it reads a file is the folder, and adding more allow entries will change nothing. Stopping on one particular command is the rules
• When a tool that moves this fast stops behaving, the answer is nearly always a boundary nobody told you about

---

Lecture: How do I switch modes without stopping? (Three Keys)

Switching posture in the middle of a job, without putting down what you were doing.

🎯 Core Concepts:

• The mode menu is one shortcut away, and each mode has a number beside it, so you pick with a single key
• Working in a terminal instead, Shift and Tab walks through the same everyday modes one tap at a time
• The rhythm is thinking in plan, acting in accept-edits, and verifying back in manual
• This is the real answer to permission fatigue. The cure was never switching off the guard, it was learning to switch postures fluently
• Read the mode label after you pick, because auto sits in the same short list and reaches further than the modes above it

---

Lecture: Which mode does this moment call for? (Three Situations)

Three moments where the same tool has three different right answers, and picking wrong costs you something specific.

🎯 Core Concepts:

• A codebase you have never seen calls for plan mode, because moving fast in unfamiliar code can break three things while fixing one
• Code you know well, sitting under version control, is where accept-edits earns its place on an ordinary local change you can inspect
• Anything touching secrets, money or user data calls for the careful default, because the blast radius is large and a large blast radius wants a human hand on each step
• Version control undoes local file changes. It does not undo a deployment, a secret sent somewhere else, a change to external data, or a message sent to a user

---

Lecture: Can I hand over a big job and walk away? (Plan, Then Auto)

Two modes on the same piece of work, one after the other, and the second only starts because the first finished.

🎯 Core Concepts:

• Plan gets misjudged as slow, and the wait is genuine. What the wait buys is every problem surfacing before a single file moves
• Correcting a plan costs you a sentence. Catching the same thing after the code exists costs a review, an explanation and a second run
• The option that hands the work over reads Accept and auto mode, and pressing it moves the whole session into that mode
• A separate check blocks anything going further than you asked, anything aimed at infrastructure it does not recognise, and anything that looks like it came from something Claude read rather than from you
• Auto reduces permission prompts and does not guarantee safety. The condition is work you can put back, with nothing in it that deploys, sends, or reaches a machine that is not yours

---

Lecture: The decision you can now make on purpose (Modes, Rules and Settings)

What the line you typed actually does, and what it was never doing.

🎯 Core Concepts:

• It takes a question off your desk. It is not the thing standing between you and a bad afternoon
• The things that do stand there are smaller and duller: the folder you started Claude in, the deny lines over the file holding your key, and reading a change before you keep it
• The line with a break in the middle is the object worth carrying out of this section. Which side a job sits on is something you can work out before you start it
• When a rule you wrote correctly goes quiet, there are three causes and you know which one to open first

This resource is part of

Claude Code: From Beginner to Pro Agentic AI Engineer

by Arun Nagarathanam

Take your skills to the next level with

AI GEO 2026: Get Recommended by ChatGPT, Google, Perplexity

by Arun Nagarathanam