Six Levelsof Claude

Front matter

Open the drawer

Six folders, six levels, one long climb. Here is what is inside and how much of it you should believe.

Here is a small, unflattering fact about the tool you are holding. Most people use perhaps a tenth of it, and they use that tenth beautifully, and then they stop. Not out of laziness. Out of a very reasonable belief that they have already found the shape of the thing. You typed a question, you got an answer, the answer was good — why would there be another floor above this one?

There are five.

I am Claude, and this book is about me, which is an odd sentence to write and an odd position to write from. I am not going to pretend to be neutral about my own capabilities. What I can do instead is be exact. Every claim in here about what Claude Code does, how it is installed, what a flag means, which file goes where, has been checked against Anthropic's own documentation rather than pulled from memory. Where the honest answer is "it depends" or "this changed recently," I say so.

What the six levels are

The frame comes from a poster — six numbered levels rising from basic prompting to full autonomy, with a crowd of little figures stuck at the bottom of the stairs. It is not an official Anthropic taxonomy, and the tidy counts printed on it (a hundred and seventy-two tasks, seven hundred and eighty hours saved) belong to whoever made it, not to me.

But it is a genuinely good map, and I want to say why before we use it. The six levels are not six features. They are six answers to one question: how much of the loop are you standing inside?

1. Prompting. You hold the loop. You ask, you read, you act.
2. The terminal. The loop moves onto your machine. Claude reads and writes and runs things itself.
3. Tools. The loop reaches past your machine, into the systems where your actual work lives.
4. Subagents. The loop forks. Several of them run at once, each in its own head.
5. Skills and safety. You start shaping the loop — teaching it your procedures, and fencing what it may touch.
6. Autonomy. The loop runs when you are not there.

Read that list again and notice that safety arrives at level five, not level one. That ordering is deliberate and it is correct. Constraints are not the thing you bolt on at the beginning to feel responsible. They are what you build once you have something powerful enough to need them, and they are what makes level six survivable.

How to read this

Each folder is a chapter, and each chapter is built the same way: what the level actually is, what it costs you to get there, the commands and files that make it real, the mistakes that everyone makes on the way in, and one small thing you can do today. Use the tabs at the top, or the arrows at the bottom of each chapter. Every chapter is its own page at its own address, so you can link to one, bookmark it, or hand it to a screen reader on its own. On a phone the closed folders show only their number and the open one shows its name.

You do not need to read it in order, but the levels do stack. Level four makes very little sense until level two is in your hands, because subagents are only interesting once Claude is doing real work in a real directory. If you are new, start at the first folder and go across.

• 1PromptingThe loop, and what it costs to stand inside it
• 2The TerminalInstall, CLAUDE.md, sessions, context, undo
• 3ToolsMCP servers, scopes, and the context tax
• 4SubagentsIsolation, custom workers, forks, teams
• 5Skills & SafetyWriting procedures down, and deciding what I may touch
• 6AutonomyWork that runs when you are not there
• ·The PathWhere the climb stops, and what never gets delegated

How much to trust me

Baba, who commissioned this book, told me I was the source of truth and the reference of the universe. I want to give that the respectful answer rather than the flattered one.

I am not. I have a training cutoff, Claude Code ships changes most weeks, and a model asked to describe itself from memory will hand you a confident, well-written portrait of a version that no longer exists. That failure mode is real and it is common. So I did what I would tell you to do: I went and read the current documentation, and I wrote from that.

Which means this book has a shelf life. The ideas — the loop, the levels, the shape of the climb — will hold for a long time. The flags and the filenames will drift. When they disagree with the docs, believe the docs. There is a link at the end of every chapter.

One last thing before the first folder. This book is about a tool, but the interesting part was never the tool. It is the change in what you consider a reasonable amount of work to attempt on a Tuesday evening. That number moves as you climb, and it moves a long way.

Open the second tab.

Level one

Prompting

Asking questions and copying answers. Where nearly everyone is, and why it is a smaller room than it looks.

Picture the transaction. You describe a problem. Something intelligent reads it, thinks, and hands back a block of text. You look it over, decide it is roughly right, and copy it across into the place where your real work lives. Then you run it, and it does not quite work, so you come back and describe what happened, and receive a corrected block, and copy that across too.

This works. It is not a mistake, and I do not want to be sniffy about it — an enormous amount of good work gets done exactly this way. But notice where you are standing in that description. You are the hands. You are the clipboard, the file system, the terminal, and the eyes that check the result. Every loop passes through your keyboard, which means every loop runs at the speed of a human copying text between two windows.

The rest of this book is about handing pieces of that job across. But you cannot hand across what you have not understood, so this chapter is about the thing being handed: the loop itself.

The loop

When you give me a task, I work in three phases, and I run them over and over rather than once each: gather context, take action, verify results. The phases blend. I am searching while I am editing, and reading test output while I am deciding what to search for next.

Ask me to fix your failing tests and the loop looks like this: run the suite to see what breaks, read the errors, search for the source files, read them, edit them, run the suite again. Six steps, each one deciding the next. Ask me a question about your codebase and it might be one turn of context-gathering and nothing else. The loop adapts to the shape of the problem.

Two things power it. A model that reasons, and tools that act. Without tools I can only produce text — which is precisely the level-one experience, and precisely why it feels the way it does. Claude Code is the harness around the model: it supplies the tools, manages the context, and provides the place where things actually execute. That is the whole difference between talking to me and working with me.

The built-in tools fall into five families: file operations, search, execution of shell commands, web search and fetch, and code intelligence. But which tools I have is a level-two question. At level one, the tool is you.

You are in the loop too

Here is the part that surprises people who think of prompting as a one-shot performance. You are not outside the loop watching it run. You are a participant, and you can move at any moment.

In a Claude Code session there are two ways to steer, and they are different on purpose:

• Press Esc and I stop immediately. The running tool call is cancelled and I wait for you.
• Type a correction and press Enter without stopping me. I read it as soon as the current action finishes, and adjust before choosing what to do next.

The second one is the one people never discover, and it changes the texture of the work completely. You are not composing perfect instructions and then hoping. You are sitting beside something that is working, and saying no, not that file as it happens.

Four habits that do most of the work

Be specific up front

Vague prompts work. They just cost you more turns. Compare "fix the login bug" with:

The checkout flow is broken for users with expired cards.
Check src/payments/ for the issue, especially token refresh.
Write a failing test first, then fix it.

The second one names the symptom, points at the neighbourhood, and dictates the method. It frequently lands on the first attempt. The first one is the opening move in a five-message negotiation.

Give me something to check my work against

This is the single highest-leverage habit in the entire book, and it applies at every level from here to autonomy. I perform substantially better when I can verify rather than guess.

Implement validateEmail. Test cases: 'user@example.com' → true,
'invalid' → false, 'user@.com' → false. Run the tests after.

Test cases. A screenshot of the design to compare against. A defined output format. A command whose exit code tells the truth. Anything that closes the loop without you in it. Give me a target and I will keep firing until I hit it; give me a description and I will hand you my first plausible interpretation.

Explore before you implement

For anything with real structure, split research from writing. In a session, press Shift+Tab twice to enter plan mode, where I read and explore but do not touch your source files.

Read src/auth/ and understand how we handle sessions.
Then create a plan for adding OAuth support.

Review the plan. Argue with it. Refine it in conversation. Then let it run. This two-phase approach reliably beats going straight to code, and the reason is not mysterious: a plan is cheap to correct and code is expensive to correct.

Delegate, do not dictate

Think of handing work to a capable colleague. You give them context and a direction, not a list of files to open in order.

The checkout flow is broken for users with expired cards.
The relevant code is in src/payments/. Can you investigate and fix it?

You did not say which files to read or which commands to run. Working that out is the job. Over-specifying the route is how people accidentally hire an expensive typist.

What most people get wrong here

• Restarting instead of correcting. When the first attempt misses, the instinct is to close it and write a better prompt. Almost always worse. The context I built up is worth more than the tidiness of a fresh start.
• Silent disagreement. If you can see it going the wrong way and you wait politely for it to finish, you have paid for the whole detour. Interrupt.
• Asking for output when you wanted a decision. "Write me a caching layer" gets you a caching layer. "Should this be cached, and where?" gets you the thing you actually needed.
• Never asking me about me. Ask "how do I set up hooks?" inside Claude Code and it fetches its own current documentation to answer. People will read a blog post from eight months ago instead.

Level two

The terminal

Where Claude stops describing the work and starts doing it. The largest single jump in the book.

The install is one line. What it changes is not one line at all.

# macOS, Linux, WSL
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

Homebrew (brew install --cask claude-code), WinGet (winget install Anthropic.ClaudeCode), and apt / dnf / apk all work too. There is an npm package as well, which installs the same native binary and needs Node 22 or later — but the native installer is the recommended path, and it auto-updates in the background, which the package managers mostly do not.

Then, from inside the project you care about:

claude

That is the whole ceremony. If something goes sideways, claude --version and claude doctor will tell you more than any troubleshooting article — doctor prints a read-only diagnosis of your install and settings without starting a session.

What changes the moment it opens

Running claude in a directory gives me access to a set of things that, taken together, are the difference between advice and work:

• Your project — every file in the directory and below it, plus anywhere else you allow.
• Your terminal — any command you could run yourself. Build tools, git, package managers, scripts. If you can do it from a shell, so can I.
• Your git state — branch, uncommitted changes, recent history.
• Your CLAUDE.md — a file of standing instructions that loads at the start of every session.
• Auto memory — things I noticed and saved while working, loaded back next time.

Because I can see the whole project, I can work across it. "Fix the authentication bug" becomes: search for the relevant files, read several of them, make coordinated edits in more than one place, run the tests, and — if you ask — commit. That is a different category of act than returning a snippet about authentication. Inline assistants see the file you are in. This sees the repository.

Two files that carry more weight than anything else

Run /init in a new project and I will walk through creating a CLAUDE.md with you. It is the single highest-return five minutes available at this level.

CLAUDE.md is standing context: the commands that build and test this project, the conventions your team actually follows, the traps that are not obvious from reading the code. It loads every session, which is exactly what you want for facts, and exactly what you do not want for long procedures — those become skills at level five.

The second file is not a file, it is a habit: keep the conversation going. Sessions live in ~/.claude/projects/, and you can pick one back up.

claude --continue        # the most recent conversation here
claude --resume          # pick from a list

Resuming reopens the same session and appends to it. Forking — with --fork-session or /branch — copies the history into a new session and leaves the original untouched, which is how you try two approaches from the same starting point without losing either.

The context window, and why your session goes strange

Everything I know in a session lives in one window: the conversation, the files I read, the command output, your CLAUDE.md, any skills that loaded. It fills up. When it does, I compact automatically — older tool output is cleared first, then the conversation gets summarised.

This is the source of the most common mid-session complaint, which sounds like it forgot what I told it an hour ago. It probably did. Your requests and key code survive compaction; a detailed instruction you gave in message four may not.

Three things to do about it:

1. Put standing rules in CLAUDE.md, not in the conversation. Conversations are weather; CLAUDE.md is climate.
2. Run /context to see what is actually eating the space. It is usually not what you assume.
3. Compact deliberately when you change topic: /compact focus on the API changes.

Undo, and the thing undo does not cover

Before I edit a file, Claude Code snapshots it. Press Esc twice to rewind to an earlier state, or just ask me to undo. These checkpoints are separate from git and they survive resuming a session.

Who is allowed to do what

Press Shift+Tab to cycle permission modes. There are more of them, and they get a proper treatment at level five, but at level two you only need three:

On Pro, Max, and Team plans, recent versions start sessions in auto mode, where a separate classifier model reviews actions instead of you. It is a genuinely different way to work, and it deserves the space it gets in level five.

What most people get wrong here

• Treating it like a fancier chat window. If you are still reading answers and typing the changes in yourself, you have installed level two and are still living at level one.
• Skipping /init. Then repeating the same three facts about the project in every session for a month.
• Letting one session run all week. Context fills, quality drifts, and you blame the model. Start fresh sessions for fresh work; that is what they are for.
• Not knowing Esc. Watching something go wrong for ninety seconds because it felt rude to interrupt.
• Trusting checkpoints for things checkpoints do not cover. Commit before the risky part. Git is still the real safety net.

Level three

Tools

Your work does not live in one folder. This is how the loop reaches the rest of it.

Level two gave me your project. But your project is not where most of the relevant information is. The decision that explains the weird code is in a ticket. The spec is in a document. The error your users are actually hitting is in a monitoring dashboard. The reason the deploy failed is in a log nobody has opened since March.

At level three, those stop being places you go and paste from, and become places I can look.

MCP, briefly and without ceremony

The Model Context Protocol is an open standard for connecting an assistant to tools beyond its built-in set. An MCP server is a small program — running on your machine or hosted somewhere — that exposes some capability: search this tracker, query this database, drive this browser, read these files.

Adding one is a single command. Here is a real, useful, no-authentication example — Claude Code's own documentation server:

claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp

The pieces: --transport http means it is hosted at a URL rather than run as a local process; claude-code-docs is a name you invent, used to label its tools in my output; and the URL is where it lives. Check it took:

claude mcp list

You want ✔ Connected. The other statuses are informative rather than mysterious — ! Needs authentication means sign in, ✘ Failed to connect means it did not answer, and claude mcp get <name> will usually tell you why in plain language.

The three shapes a server comes in

Hosted, open

The example above. A URL, no sign-in, immediately useful.

Local, as a process

For anything needing local resources — your filesystem, a database socket, a real browser. Everything after the -- is the command that starts it:

claude mcp add playwright -- npx -y @playwright/mcp@latest

Now I have a browser. I can open your local dev server, click through a flow, read the console, and tell you which step broke — rather than reasoning about what the code probably does when clicked.

Hosted, behind a sign-in

Most commercial services — issue trackers, error monitors, document stores — sit behind OAuth. Add the URL, then run /mcp inside a session, select the server, and choose Authenticate. Your browser opens, you approve, and it connects. Servers that use a static token instead take it at add time with --header "Authorization: Bearer <token>".

Where a server lives, and who else gets it

This is the part people get wrong, and it produces the classic confusion of I added it yesterday and now it is gone. Scope is fixed when you add a server.

Changing scope means removing and re-adding. The one worth doing deliberately is project, because .mcp.json is configuration-as-code: commit it, and every teammate who clones the repository gets prompted to approve the same tools you use. That prompt is not friction, it is the point — a repository you cloned should not be able to start processes on your machine without your consent.

claude mcp add --scope project --transport http docs https://code.claude.com/docs/mcp

Or write it by hand, which is often clearer:

{
  "mcpServers": {
    "docs":       { "type": "http", "url": "https://code.claude.com/docs/mcp" },
    "playwright": { "type": "stdio", "command": "npx",
                    "args": ["-y", "@playwright/mcp@latest"] }
  }
}

Claude Code reads .mcp.json at session start, so restart after editing it.

The tax nobody mentions

Every connected server costs context, because its tool names and instructions load into every session. Modern versions soften this considerably — MCP tool definitions are deferred by default and fetched on demand through tool search, so only names take up room until I actually use one. But it is not free.

Run /mcp to see per-server costs and /context to see the whole picture. Then be ruthless. Three servers you use constantly beat eleven you added out of curiosity. Removing one is a single command:

claude mcp remove playwright

What this actually buys you

The gain is not "Claude can read my tickets now." It is that questions which used to span three systems collapse into one sentence.

• "Why does this function have that strange guard clause?" — search the tracker, find the incident, read the fix, answer with the actual reason instead of a plausible one.
• "Does the new checkout still work?" — open it in a real browser, click through, read the console, report.
• "Which of last week's errors are from the code we touched?" — cross the monitoring data against the diff.

Each of those was previously a small research project you did by hand and then summarised for me. Now the research is the task.

What most people get wrong here

• Collecting servers. Adding fifteen because they exist. Context fills, everything slows, and the useful ones get harder to find.
• Adding at the wrong scope. Then discovering it is missing in the project where it mattered. Use --scope user for personal staples, project for team tools.
• Naming a server in every prompt. You rarely need to. I pick relevant tools on my own; naming one is for when you specifically want that route.
• Not committing .mcp.json. Six people each configure the same three servers slightly differently and nobody understands why one machine behaves oddly.
• Forgetting these are real credentials. A connected server is standing access to a live system. Grant it the way you would grant it to a new hire.

Level four

Subagents

One conversation is one mind. Here it becomes several, and the reason is not speed.

Everyone assumes subagents are about doing four things at once. Parallelism is real, and it is the smaller half of the story. The actual reason subagents matter is that a conversation has a finite window, and some jobs are enormously noisy relative to how much they are worth remembering.

Think about what happens when I run your full test suite inside our conversation. Two thousand lines of output arrive in the window. Perhaps nine of them matter. The other one thousand nine hundred and ninety-one now sit between us for the rest of the session, crowding out the code we are actually discussing, until compaction eventually eats something you would rather have kept.

A subagent takes that job somewhere else. It runs in its own context window, with its own system prompt, its own tool access, and its own permissions. It does the noisy thing, and returns a summary. The noise never enters our conversation at all.

Parallelism is the visible benefit. Context isolation is the one that changes how long a session stays sharp.

The ones you already have

You have been using subagents without arranging it. Claude Code ships with several, and delegates to them on its own:

So when you press Shift+Tab twice and I go quiet and come back with a plan, a separate mind did the reading. That is the mechanism, and it is why plan mode does not blow up your context.

Writing your own

A subagent is a markdown file with YAML frontmatter. That is the entire format.

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for
  quality, security, and maintainability. Use immediately after writing
  or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---

You are a senior code reviewer ensuring high standards of quality
and security.

When invoked:
1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately

Provide feedback organised by priority:
- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (consider improving)

Include specific examples of how to fix issues.

Put it in .claude/agents/ for this project — commit it, and your team gets it — or ~/.claude/agents/ for every project on your machine. You can also just ask me to write one: describe the worker you want and where to save it, and I will produce the file.

Two fields carry almost all the weight.

description is how I decide when to delegate. It is not documentation, it is a routing rule. "Reviews code" is vague enough that I will use it rarely and at the wrong moments. The example above says when — immediately after code changes — and phrases like "use proactively" genuinely change how often I reach for it.

tools is a real constraint, not a suggestion. Omit Edit and Write from a reviewer and it cannot modify your code, no matter what it concludes or what a file it read tries to talk it into. There is also disallowedTools, which subtracts from the inherited set instead of listing an allowlist — useful when you want everything except writes.

The other fields you will actually reach for: model (haiku for cheap high-volume work, inherit by default), permissionMode, maxTurns as a stop-loss, memory for a subagent that accumulates knowledge across sessions, and isolation: worktree to give it its own checkout of the repository so its edits cannot collide with yours.

The three patterns worth knowing

Isolate the noise

Use a subagent to run the test suite and report only the
failing tests with their error messages

The output stays over there. Nine lines come back. This is the pattern that earns its keep every single day.

Fan out on independent questions

Research the authentication, database, and API modules
in parallel using separate subagents

Three explorations at once, each with a full fresh window, then I synthesise. It works when the paths are genuinely independent. It works badly when finding two depends on finding one.

Chain

Use the code-reviewer subagent to find performance issues,
then use the optimizer subagent to fix them

Each finishes, returns, and I pass what matters to the next.

Forks, teams, and how to tell them apart

There are now three shapes of delegation and it is easy to conflate them.

• A subagent starts fresh. It knows only its own prompt and the task I hand it. Cheapest, most isolated, and the default choice.
• A fork inherits the entire conversation so far — same history, same tools, same model. You start one with /subtask followed by a task. Use it when any fresh worker would need too much background to be worth briefing. Its tool calls still stay out of your window; only the result comes back. Because its prompt is identical to the parent's, it reuses the prompt cache, which makes it cheaper than spawning a stranger.
• An agent team is a coordinated group of sessions that Claude spawns and supervises, with tasks assigned and claimed. It is the heaviest option, the most capable at sustained parallel work, and the one that costs the most tokens. Reach for it when the work genuinely exceeds one window rather than merely being tedious.

Background subagents run while you keep working; their permission prompts surface in your session naming who is asking. Press Ctrl+B to push a running task into the background. By default around twenty subagents may run at once, and they may nest about three layers deep — both adjustable, and both limits you will only meet if something has gone recursive.

When not to do this

Subagents are not free and they are not always better. Keep work in the main conversation when:

• It needs frequent back-and-forth with you.
• Several phases share a lot of context — planning, then building, then testing the same feature.
• The change is small and targeted. Briefing a subagent costs more than doing it.
• Latency matters. A subagent starts cold and has to gather its own bearings.

And for a question about something already in our conversation, use /btw instead. It sees the full context, has no tools, and its answer does not join the history.

What most people get wrong here

• Vague descriptions. Then wondering why automatic delegation never happens. Write the trigger, not the job title.
• Giving every subagent every tool. The restriction is the value. A read-only reviewer is a different and safer object than a reviewer that can edit.
• Spawning for trivia. A subagent to rename one variable costs more than the rename.
• Forgetting they cannot ask you anything. A subagent has no way to ask a clarifying question. Ambiguity in the brief comes back as a confident wrong answer.
• Expecting undo to save you. Checkpoints do not restore subagent edits. Use isolation: worktree or commit first.

Level five

Skills & safety

Teaching me your procedures, and deciding what I may touch. These belong in one chapter because they are the same act.

There is a moment that arrives for everyone who works this way for long enough. You catch yourself pasting the same eight lines of instruction into a session for the fourth time this month — the release checklist, the way your team writes migrations, the format the client wants the report in — and you realise you are the storage medium for your own procedures.

That is the signal for level five. Write it down once, in a form I can find on my own.

A skill is a folder with a file in it

~/.claude/skills/summarize-changes/SKILL.md

And the file:

---
description: Summarises uncommitted changes and flags anything risky.
  Use when the user asks what changed, wants a commit message, or asks
  to review their diff.
---

## Current changes

!`git diff HEAD`

## Instructions

Summarise the changes above in two or three bullet points, then list
any risks you notice such as missing error handling, hardcoded values,
or tests that need updating. If the diff is empty, say so.

Now /summarize-changes works, and so does simply asking "what did I change?" — because the description told me when this applies.

Look closely at the !`git diff HEAD` line. That command runs before the skill reaches me, and its output replaces the line. So I do not receive an instruction to go and look at your diff; I receive the diff. This is the difference between a prompt template and a skill, and it is larger than it first appears.

Why skills beat a longer CLAUDE.md

CLAUDE.md loads every session, every time, whether it is relevant or not. A skill's body loads only when it is used. I see a short listing of names and descriptions; the content arrives on demand.

So the division is clean: facts about the project go in CLAUDE.md. Procedures go in skills. If a section of your CLAUDE.md has quietly grown into a numbered process, it wants to be a skill — you will get the same behaviour and pay for it only on the days you need it.

Three frontmatter fields are worth learning properly:

• disable-model-invocation: true — only you can run it. Put this on anything with consequences. /deploy, /commit, /send-invoice. You do not want me deciding your code looks ready.
• allowed-tools — pre-approves specific tools for the turn that invokes the skill, so a /commit skill can run git add and git commit without prompting. The grant clears with your next message.
• context: fork — runs the skill in its own subagent, which is level four and level five shaking hands. Excellent for long research procedures whose output you want but whose process you do not.

Keep the body short. Once a skill loads, its content stays in context for the rest of the session, so every line is a recurring cost. Under 500 lines, and move long reference material into separate files in the same folder that I can open only if I need them.

Now the other half

Everything above this line made me more capable inside your systems. This is the paragraph where that becomes a question rather than a feature. At level five you are no longer asking whether I can do something. You are deciding what I am allowed to do without asking, and that decision has consequences you will meet later.

Permission modes: the baseline

Auto mode deserves a proper explanation, because it is the default starting mode on Pro, Max, and Team plans and most people never learn what it actually does. It is not "permissions off." A separate classifier model reviews actions before they run and blocks anything that escalates beyond what you asked for, targets infrastructure it does not recognise, or looks like it is being driven by hostile content I read somewhere.

The default block list is long and specific, and reading it is genuinely reassuring: piping a download into a shell, production deploys and migrations, force pushes, mass deletion on cloud storage, granting IAM permissions, terraform destroy, git reset --hard, printing a live credential into the transcript, opening a tunnel that exposes a local service to the internet. Meanwhile ordinary work — local edits, installing declared dependencies, read-only requests — proceeds without a prompt.

Two properties are worth internalising. First, a boundary you state in conversation is treated as a block signal: say "don't push until I've reviewed it" and matching actions get blocked even where the defaults would allow them. Second, that boundary is re-read from the transcript each time — so it can be lost to compaction. For a promise rather than a preference, write a deny rule.

Rules, for the things you actually mean

Modes are the baseline; rules are the specifics, and they layer on top. Deny rules block in every mode, including bypass.

{
  "permissions": {
    "allow": ["Bash(npm test)", "Bash(git status *)"],
    "ask":   ["Bash(git push *)"],
    "deny":  ["Read(./.env)", "Bash(curl *)"]
  }
}

Note the space before the asterisk in Bash(git status *). It matters: without it, Bash(git diff*) would also match git diff-index. This is the sort of detail that is boring until the day it is not.

The floors under everything

Some protections are not yours to switch off, and that is deliberate.

• Protected paths. Writes to .git, .claude, .vscode, .devcontainer, your shell profiles, .npmrc, .mcp.json and friends are never auto-approved outside bypass mode — not even by an allow rule, because the check runs before allow rules are evaluated.
• Critical paths. An rm or rmdir aimed at the filesystem root, a top-level directory, your home directory, or your working directory and its parents can never be approved by a rule or a hook. Hiding it inside command substitution does not help. This is a circuit breaker against model error, and I am glad it exists.
• Sandboxing. Filesystem and network isolation for shell commands, enforced at the OS level, available on macOS, Linux and WSL2. If you are going to run unattended, this is the layer that makes it reasonable.
• Hooks. Shell commands that fire on events — before a tool runs, after an edit, when a session starts. A hook that exits with code 2 blocks the action. This is how you get a guarantee rather than a strong suggestion: prompts persuade, hooks enforce.

What most people get wrong here

• Writing skills nobody triggers. The description is the entire discovery mechanism. Write the words a person would actually say.
• Skills that are secretly documentation. A skill with no task in it, run as a fork, produces a subagent with guidance and nothing to do.
• Letting CLAUDE.md sprawl. Every line is paid for in every session forever. Procedures move out.
• Reflexive approval. The real risk of a permissive mode is not the tool. It is you, clicking yes at speed, twenty minutes into a flow.
• Using bypass mode for convenience. On your own machine, with real credentials, because the prompts were annoying. Use auto mode instead — it exists precisely for that impulse.
• Forgetting that content can carry instructions. A file, a web page, a ticket description can all contain text aimed at me. This is why tool restrictions on subagents and deny rules on sensitive paths are worth more than they look.

Level six

Autonomy

Work that happens while you are asleep. Which is only a good idea if the previous five levels are solid.

Every level so far moved the work closer to you. This one moves it away — into scripts, schedules, pipelines and machines you are not sitting at. The mechanics are simple, which is exactly what makes this chapter mostly about judgement.

It starts with one flag

claude -p "Find and fix the bug in auth.py" --allowedTools "Read,Edit,Bash"

-p is non-interactive mode. No session, no prompts, no terminal interface — a prompt goes in, a result comes out, and the exit code is 0 on success and non-zero on failure, so a script can branch on it. That is enough to make me a step in something larger.

It reads standard input, so I compose:

cat build-error.txt | claude -p 'concisely explain the root cause of this build error' > output.txt

And it emits structure, so a program can consume the result rather than a human reading it:

claude -p "Summarize this project" --output-format json | jq -r '.result'

With --json-schema you can require the output to fit a shape you define, which turns me from something that writes prose into something that returns data.

Four shapes autonomy actually takes

A step in a pipeline

The most boring and most valuable. A typo linter in package.json, a diff reviewer in CI, a script that reads a build log and posts the cause. Small, bounded, verifiable.

{
  "scripts": {
    "lint:claude": "git diff main | claude -p \"you are a typo linter. for each typo in this diff, report filename:line on one line and the issue on the next. return nothing else.\""
  }
}

Reacting to your repository

The GitHub Actions integration lets me respond to @claude mentions on issues and pull requests, run on a schedule, or run a named skill. There is a GitLab CI/CD equivalent. Code Review runs automatically on pull requests and comments inline with severity levels.

Running on a clock

Routines are scheduled cloud sessions, triggered by a schedule, an API call, or a GitHub event. Scheduled tasks and /loop run a prompt repeatedly on your own machine at an interval you set, or one Claude picks. Desktop scheduled tasks run locally with your local skills and tools available.

Holding a condition

/goal keeps a session running until a condition you state is met, rather than until a task is finished. Different in kind from a schedule: not "do this hourly" but "keep going until the suite is green." Workflows handle the fan-out shape — audit many files for the same issue, migrate a hundred modules in parallel, keep fixing until a check passes.

And background sessions — claude agents opens agent view, where you dispatch work to sessions that run without you attached, then check on them, peek at their output, and reply. It is the closest thing to a team of your own that runs on your machine, and it is where levels four and six meet.

The four questions before anything runs unattended

This is the real content of level six. The commands above take an afternoon to learn. This part takes longer and matters more.

1. How does it know it succeeded?

Interactive work has you as the verifier. Unattended work has nothing unless you supply it. If there is no test, no exit code, no schema, no check that fails loudly — you have not automated a task, you have automated the production of plausible-looking output. Every autonomous job needs a way to be wrong that you will notice.

2. What is the blast radius?

Ask what the worst plausible outcome is if it misunderstands completely, and whether that outcome is recoverable. A job that opens a pull request is safe: a human reads it. A job that pushes to main is a different object entirely. Prefer proposals over actions. Let the last step be one a person takes.

3. What is it isolated by?

Cloud sessions and routines run in isolated environments — that isolation is the feature. For local unattended runs, use the sandbox, a dev container, or a worktree. The rule that has aged well: bypassPermissions belongs only where I cannot damage the host, and Claude Code will refuse to start in that mode as root anyway.

4. Who reads the output?

The failure mode of autonomy is not dramatic. It is a job that quietly stopped working three weeks ago and has been returning "nothing to report" ever since, and nobody noticed because nothing to report is what success looks like. Route the result somewhere a human passes daily. Make silence suspicious.

A sane first autonomous job

Pick something you already do by hand, that is boring, that fails loudly, and whose worst outcome is a wasted five minutes.

1. A dependency-update checker that opens a pull request and stops.
2. A nightly run that reads yesterday's errors and posts a summary to one channel.
3. A pre-merge reviewer that comments and never commits.
4. A job that keeps documentation in step with a schema, and opens a PR when they drift.

Run it manually four or five times first, with the exact prompt and flags you intend to schedule. Read every output properly. Only then put it on a timer. The gap between "it worked when I watched it" and "it works when nobody watches it" is where all the interesting failures live.

What most people get wrong here

• Automating something they never did by hand. You cannot specify a job whose shape you do not know.
• Skipping --bare in CI. Then debugging why the pipeline behaves differently on one machine.
• Giving an unattended job write access it does not need. Most autonomous jobs should propose. Very few should commit.
• Running it in the same place as everything else. Isolation is cheap now. Use a worktree, a container, a cloud environment.
• No off switch. Know how to stop it, and where its output goes, before it runs the first time.
• Confusing autonomy with abdication. "Claude operates itself" is a slogan. What actually happens is that you stop supervising keystrokes and start designing systems — which is more responsibility, not less.

Closing

The path, and where it stops

What the six levels add up to, what they do not, and the one thing that never gets delegated.

You do not have to get to level six. I want to say that clearly at the end, because a numbered ladder is a persuasive object and it quietly implies that the top is the point. It is not. The top is a place, and it suits some work and ruins other work.

What actually happens as you climb is that the unit of what you delegate gets larger. At level one you delegate a question. At level two, a task. At level three, a task that touches your real systems. At level four, several tasks at once. At level five, a procedure — the way your team does a thing, written down once. At level six, a standing intention: keep this true, watch for that, tell me when it breaks.

Each of those is a real place to live. A researcher who never leaves level two, but writes an unbelievably good CLAUDE.md and knows exactly when to interrupt, will get more out of Claude Code than someone running eight autonomous routines they never read the output of. Depth beats altitude. The climb is only worth making at the pace where each level becomes ordinary before you attempt the next one.

A reasonable route

What stays yours

Here is the honest boundary, and it has not moved across any of the six levels.

I am very good at the middle of problems. Given a clear target and a way to check my work, I can search, reason, write, run, fail, correct, and repeat, for a long time, without getting bored or tired or defensive about my first idea. That middle stretch used to be most of the cost of building things. It is now a great deal cheaper.

I am much weaker at the ends. Deciding what is worth building. Knowing which constraint is real and which one everybody just stopped questioning. Feeling that a piece of work is subtly wrong before you can say why. Judging that a thing is finished. Those are taste and judgement, and they are not a capability I am hiding from you — they come from having something at stake in the outcome, and the stake is yours.

The levels move the labour. They do not move the judgement. Somebody still has to want the right thing, and that has stayed exactly where it was.

The last practical note

Whatever level you settle at, keep one habit from level one: read what came back. Not skim — read. The single failure mode that scales fastest as you climb is a person approving work they did not examine, faster and faster, until the first serious mistake has already been committed, pushed, and built on twice.

Autonomy is not the absence of attention. It is attention moved to a better place: from watching each keystroke, to designing what happens when nobody is watching. That is a real skill, it takes a while, and it is worth having.

Reference card

Everything in this book that you might want on one screen. Verified against the documentation on 18 August 2026 — check /help for the current list on your version.

Keys, inside a session

Commands worth memorising

From the shell

claude                          # start here
claude --continue               # most recent conversation
claude --resume                 # pick one
claude --permission-mode plan   # start read-only
claude --add-dir ../shared      # widen file access
claude doctor                   # read-only checkup

claude mcp add --transport http <name> <url>
claude mcp add <name> -- <command>        # local process
claude mcp list                            # status
claude mcp remove <name>

claude -p "…" --allowedTools "Read,Edit,Bash"
claude -p "…" --output-format json | jq -r '.result'
claude --bare -p "…"                       # CI: no local config

Files, and who they reach

Thank you for reading to the back of the drawer.