Every Claude Code session runs in a permission mode, and the mode decides what the agent may do before it asks you. Pick the wrong one and you either spend an hour typing “yes”, or the agent runs a command nobody wanted. This lesson goes through all six modes, and it ends with a rule that protects our database in every one of them.

What Each Mode Allows

A permission mode is a setting for the whole session that decides how much the agent may do on its own. Claude Code has six of them.

Here they are from the most supervised to the least, each with its config value, which is the name you type on the command line or in a settings file:

• Manual (default, or manual on the command line). The agent reads files on its own and asks you before every edit and every command. Use it on code you do not know yet, or on sensitive work where you want to approve each step.
• Accept edits (acceptEdits). The agent creates and edits files in your folder without asking, and it runs simple file commands such as mkdir, mv and cp. Every other command still needs your yes. Use it when you plan to review the changes afterwards, in your editor or with git diff.
• Plan (plan). The agent reads the code, explores, and writes a plan. It edits nothing until you approve that plan. Use it before a change that touches several files, or when you are not sure of the approach yet. Lesson 4.2 runs a real feature through it.
• Auto (auto). The agent works without asking, and a second model, the classifier, checks each action before it runs. It blocks the risky ones, such as downloading and running a script, a force push, or deleting files that existed before the session. Use it for everyday work on a task whose direction you trust. It is the mode a new session starts in.
• Don’t ask (dontAsk). Anything that would ask you is refused instead. Only reads, read-only commands and what you allowed in advance can run. Use it for scripts and automated runs, where nobody is there to answer a question.
• Bypass permissions (bypassPermissions). No checks at all, so every action runs at once. Use it only inside a container or a virtual machine that the agent cannot damage, because nothing stops a wrong command.

Switching Modes

Press Shift+Tab to move to the next mode. From auto mode, the first press goes to Manual, the next to Accept edits, then to Plan, and then back to auto.

The mode line under the prompt bar shows where you are: auto mode on, manual mode on, accept edits on or plan mode on.

A new session in a terminal starts in auto mode. On Pro, Max and Team plans, that has been true since v2.1.228, and since v2.1.233 on native Windows. Since v2.1.283, it is true for every interactive terminal session.

Before those versions, a session started in Manual. It also starts in Manual when auto mode is not available to you, for example because your company switched it off.

Your first session after an install or an upgrade can start in Manual too, before Claude Code has fetched its settings. So do not assume the mode. Look at the mode line.

Don’t ask and Bypass permissions are not in the Shift+Tab cycle. You choose them, like any mode, when you start a session. The claude --help output lists all six:

  --permission-mode <mode>              Permission mode to use for the session
                                        (choices: "acceptEdits", "auto",
                                        "bypassPermissions", "manual",
                                        "dontAsk", "plan")

For example, claude --permission-mode plan starts a session in plan mode.

Deny Rules

Modes decide when the agent asks. A deny rule is different: it names a command the agent may never run, in any mode. That includes auto, don’t ask and bypass permissions, the modes that ask you least. No allow rule can override it.

Repair Desk uses a SQLite database, and the one command we never want to see run by accident is dotnet ef database drop. So we deny it in .claude/settings.json at the root of the solution. This is the full file, including the status line entry from the previous lesson:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "statusLine": {
    "type": "command",
    "command": "powershell -NoProfile -ExecutionPolicy Bypass -File .claude/statusline.ps1"
  },
  "permissions": {
    "deny": [
      "Bash(dotnet ef *database drop*)",
      "PowerShell(dotnet ef *database drop*)"
    ]
  }
}

The rule appears twice, because Claude Code runs a shell command through its Bash tool or its PowerShell tool, and with Git Bash installed one session may use both. With this file in place, an attempt to drop the database gets a refusal instead of an empty database, in every mode. The star before database matters, because dotnet ef also accepts its options first, before database: dotnet ef --project src/RepairDesk.Data database drop.

A rule that began dotnet ef database drop would miss that spelling. Module 6 builds a full set of permission rules for the .NET tools on top of this one.

The file holds a second entry.

The statusLine entry runs the PowerShell script. On macOS or Linux, change its command to bash .claude/statusline.sh. Claude Code picks up the change as soon as you save the file, and the status line from lesson 1.5 appears at the bottom of the screen.

Exercise: Checking the Agent’s Answers

Open a session in your module-01 folder and ask the agent three questions about the loaner bikes feature, which does not exist in the solution yet. For example, ask where loaner bikes are stored, which endpoint returns them, and which test covers them.

Save the answers. In module 4 we build the loaner bikes feature, and then you can compare what the agent guessed with what got built.

Then check each answer against the folder. An agent asked about code that does not exist may answer from the shape of the code that does, and name files nobody wrote. Or it may search, find nothing, and tell you the feature is not there yet. That answer is right, and it does not mean the exercise failed.

The check against the folder is the exercise, whichever answer you got. If you can tell on your own whether each claim is true, you have the skill the rest of this course builds on.

Where We Are

One file is new since the previous lesson, .claude/settings.json, and no C# changed. The build has zero warnings, and the tests pass with 3 unit tests and 5 integration tests. The module-01-complete folder is this exact state.

That completes module 1. In module 2, we open the agent up and look at how it works: how it gathers context, how it decides what to do, and how it checks its own work.