Chapter 9A · Autonomy & Control 01 / 21
Mastering Claude Code · A 10-Part Series

Advanced Features I — Autonomy & Control

Part 1 of 2. Plan before you build, choose who approves each action, and let work run without you — in the background, on a schedule, headless in CI, inside sandboxes and worktrees. Part 2 covers sessions, surfaces & settings.

Sid Dani · June 2026
01 · The Dial

Every feature in this chapter turns the same dial: how much you supervise

Advanced features extend the core loop with planning, reasoning, automation, and control mechanisms. They cluster into four moves — and together they're what lets Claude work on harder problems with less of your attention, safely.

Think first

Plan & reason

Planning mode, Ultraplan cloud drafting, extended thinking effort levels.

Decide who approves

Permission control

Six permission modes, plus auto mode's background safety classifier.

Run without you

Automation

Background tasks, the Monitor tool, dynamic workflows, scheduled tasks, headless CI.

Contain the blast

Isolation

OS-level sandboxing and git worktrees keep autonomous work fenced in.

The chapter's other half — session management, interactive features, surfaces like web, desktop and remote control, and configuration — is Part 2. This deck is the autonomy story.
02 · Planning Mode

Plan first when the task is big — Claude drafts, you approve, then it builds

Planning mode is a two-phase approach: Claude analyzes the task and writes a detailed implementation plan; only after you approve does it execute. The plan comes back with phases, steps, estimates — and a prompt: yes / no / modify. Say "modify — skip the queue for now" and the plan updates before a line is written.

✅ Worth a plan

  • Complex multi-file refactoring
  • New feature implementations
  • Architectural changes
  • Database migrations, major API redesigns

❌ Skip the plan

  • Simple bug fixes
  • Formatting changes
  • Single-file edits
  • Quick queries
The payoff is fourfold: a structured approach, review before execution, risks surfaced early, and clear phases and milestones. Plan mode is also a permission mode — read-only research — which slide 11 puts on the ladder.
03 · Planning Power-Ups

Four doors in, and two power-ups: Opus drafts while Sonnet executes

Ways to activate

/plan <task>Slash command inside the REPL
claude --permission-mode planCLI flag at launch
"defaultMode": "plan"Settings — make plan the default under permissions
Shift+Tab · Alt+MCycle permission modes from the keyboard

Power-ups

  • claude --model opusplan — a model alias that uses Opus for planning, Sonnet for execution
  • Ctrl+G — open the current plan in your external editor for detailed edits
  • Plan files are named after the prompt that produced them (v2.1.112) — easier to browse and reuse
Hardened in v2.1.136: plan mode now blocks all file writes — even when a matching Edit(...) rule sits in permissions.allow. The old bypass is closed; if a workflow depended on it, exit plan mode (Shift+Tab) before editing.
04 · Plan Anatomy

A good plan is phases with estimates, a risk level, a rollback path, and success criteria

The chapter ships five full planning sessions — a blog REST API (8 phases, 4.5 h), a MongoDB→PostgreSQL migration (10 days, dual-write rollback), a React class→hooks refactor (46 components, 39 h), a security hardening pass (OWASP Top 10), and an e-commerce performance overhaul (Core Web Vitals targets). They share one skeleton:

1Structure

Numbered phases with time estimates, file counts, an ordered migration path (leaf components first, App.jsx last), and a technology summary.

2Safety rails

A named risk level, a rollback strategy (keep MongoDB on dual-write), gradual cutover, and continuous validation between phases.

3Judgment

Success criteria (zero data loss, <5% regression) and expected impact per phase ("image optimization: −40% load time") so you can re-order by payoff.

The examples' verdict on when to plan: always for multi-day projects, team collaborations, critical system changes, learning new concepts, complex refactors — never for bug fixes, small tweaks, quick experiments. And review before approving: spotting a missing rollback in the plan is cheaper than meeting it in production.
05 · Ultraplan

Ultraplan drafts the plan in the cloud while your terminal stays free

/ultraplan hands a planning task to a Claude Code on the web session running in plan mode. The cloud session clones your GitHub repo, researches it, and writes the plan while you keep coding locally — then you review in the browser, with inline comments, reactions, an outline sidebar, and a shareable URL.

Three ways in

  • /ultraplan <prompt> — explicit
  • The keyword ultraplan anywhere in a normal prompt
  • From a finished local plan: "refine with Ultraplan" in the approval dialog
◇ ultraplanResearching + drafting
◇ needs your inputClarifying question waiting
◆ ultraplan readyReview in the browser

Two execution paths

  • Approve in the browser — the cloud session implements and opens a PR
  • Teleport back to terminal — implement here, start a new session, or cancel (saves the plan to a file)

Fine print

Research preview, v2.1.91+; v2.1.101 auto-creates the cloud environment on first run. Needs a Claude Code on the web account and a GitHub repo. Not on Bedrock, Vertex, or Foundry.

Warning: Remote Control disconnects when ultraplan starts — both share the claude.ai/code interface, so only one can be active (Remote Control is covered in Part 2).
06 · Extended Thinking

Thinking is on by default — the effort ladder decides how hard the model reasons

Extended thinking is deliberate step-by-step reasoning: break the problem down, weigh approaches, reason through edge cases. It's enabled by default on all models; what you tune is the effort level. The keyword "ultrathink" in a prompt activates deep reasoning on demand.

low ○ · medium ◐ · high ●Available on Opus 4.8 / 4.7 / 4.6 and Sonnet 4.6. Default is high on Opus 4.8, 4.6, Sonnet 4.6
xhighOpus 4.8 and 4.7 only (the 4.7 default); falls back to high elsewhere
maxAll four effort models, session-only
Haiku 4.5No effort levels; other models get a fixed budget up to 31,999 tokens

Controls

  • Option+T / Alt+T toggle · Ctrl+O view the reasoning
  • /effort high · claude --effort high
  • CLAUDE_CODE_EFFORT_LEVEL=high
  • MAX_THINKING_TOKENS=16000 custom budget
One menu item is a trap: ultracode is not an effort level — it sends xhigh and has Claude orchestrate dynamic workflows (slide 15), session-only. Use high effort for architectural decisions and complex problem-solving; don't burn it on simple queries.
07 · Auto Mode

Auto mode lets Claude run alone while a second model reviews every action

Auto Mode (Research Preview, March 2026) is a permission mode where a background safety classifier — running on Claude Sonnet 4.6 — reviews each action before execution. Claude works autonomously; dangerous operations get blocked, and the classifier's extra tokens are the price of not watching.

Requirements

  • Plan: Team, Enterprise, or API — not Pro or Max
  • Model: Sonnet 4.6 or Opus 4.8
  • Provider: Anthropic API only

Getting in — a short history

  • Originally unlocked with claude --enable-auto-mode, then Shift+Tab to it
  • v2.1.112: flag no longer required — Max subscribers reach it directly on Opus 4.7
  • v2.1.158: opt-in on Bedrock / Vertex / Foundry via CLAUDE_CODE_ENABLE_AUTO_MODE=1
  • Or just set it: claude --permission-mode auto / "defaultMode": "auto"
The mental model: acceptEdits trusts you to watch commands; auto mode replaces your watching with a classifier — plus hard fallbacks when the classifier gets nervous. Next slide: exactly how it decides.
08 · The Classifier

Four gates decide each action — and control returns to you when "no" piles up

1 Explicit allow / deny rules
Your permission rules are checked first — an explicit match settles it immediately.
rule wins
no explicit rule matched
2 Read-only & edits lane
File reads and edits pass automatically — no classifier call spent on them.
auto-approved
everything else — commands, network, deploys
3 Background classifier
Sonnet 4.6 reviews the action and verdicts it against the built-in and configured rules.
allow block
3 consecutive blocks · or 20 total in a session
4 Fallback — prompt the human
Auto mode stops guessing and starts asking. You always retain control when the classifier can't confidently approve.
you decide
The order matters: your rules outrank the classifier, cheap lanes are pre-cleared, and the model only judges what's genuinely ambiguous.
09 · Auto Mode Rules

The defaults block the catastrophic and allow the local — extend them, don't replace them

Blocked by default

curl | bashPipe-to-shell installs
keys over networkSending sensitive data externally
prod deploys · IAMProduction targets, permission changes
rm -rf · force pushMass deletion, force push to main

Allowed by default

Local file operations · declared dependency installs (npm install from manifest) · read-only HTTP · pushing to the current branch. Print the full set: claude auto-mode defaults

Extending without clobbering

{
  "autoMode": {
    "allow": ["$defaults", "Bash(gh pr list:*)"],
    "soft_deny": ["$defaults", "Bash(kubectl delete:*)"],
    "hard_deny": ["Bash(git push --force*)"]
  }
}

"$defaults" (v2.1.118) appends to the built-ins — before that, any user array silently replaced them. hard_deny (v2.1.136) blocks a class of actions regardless of inferred intent — unlike soft_deny, it is not negotiable by the classifier.

Enterprises define trusted CI/CD targets via the autoMode.environment managed setting — same "$defaults" append pattern.
10 · DIY Baseline

No Team plan? Seed a conservative allowlist by script — autonomy without the classifier

The chapter ships setup-auto-mode-permissions.py — a script that seeds ~/.claude/settings.json with a read-only, local-inspection baseline, then lets you widen it deliberately, one opt-in flag at a time.

# preview, nothing written
python3 setup-auto-mode-permissions.py --dry-run

# apply the conservative baseline
python3 setup-auto-mode-permissions.py

# widen only when you need it
python3 ... --include-edits --include-tests
python3 ... --include-git-write --include-packages
baselineRead / Glob / Grep / Agent / WebSearch, plus git status·log·diff, ls, cat, find
--include-editsEdit / Write / NotebookEdit
--include-testspytest, cargo test, go test, make
--include-git-writeadd, commit, checkout, stash, tag
--include-packagesnpm ci/install, pip install
--include-gh-write/readgh pr create · gh pr/issue/repo view
Dangerous operations — rm -rf, sudo, force push, DROP TABLE, terraform destroy — are intentionally excluded from every tier. The script is idempotent: run it twice, no duplicate rules.
11 · Permission Modes

Six modes form a ladder — each step changes what runs without asking, and who gates it

modewhat executes without a prompt — bar length = scopewho gates the rest
plan
reads only
nobody — writes blocked outright (research mode)
default
reads only
you — prompted for every other action
acceptEdits
reads + file edits
you — prompted for commands
dontAsk
your pre-approved tools only
nobody — everything else is denied, not prompted
auto
everything the classifier passes
the background safety classifier (Research Preview)
bypassPermissions
everything — no permission checks
nobody — dangerous; sandboxes only
Cycle the ladder live with Shift+Tab; set a rung as home base with --permission-mode or permissions.defaultMode. The pairings: plan for code review, default for pair programming, acceptEdits for automation, auto for autonomous work with guardrails.
12 · Sharper Edges

Recent releases re-cut both ends of the ladder — know what your mode actually permits

acceptEdits got more careful (v2.1.160)

Even with edits auto-approved, Claude now prompts before writing shell-startup files (.zshenv, .zlogin, .bash_login, ~/.config/git/) and code-executing build configs (.npmrc, .yarnrc*, bunfig.toml, .bazelrc, .pre-commit-config.yaml, .devcontainer/…).

Why: a "file edit" to those paths is really arbitrary command execution on your next shell or build.

bypassPermissions got broader (v2.1.121/126)

--dangerously-skip-permissions now also skips prompts for writes to .claude/skills/, .claude/agents/, .claude/commands/, .claude/, .git/, .vscode/, and shell config files.

Catastrophic removals (rm -rf /) still prompt regardless of mode — but treat the flag as a sharper tool than before: throwaway sandboxes only.

Same lesson from both ends: mode names are stable, their edges move per release. The middle of the ladder grew a guard; the bottom lost several. (The chapter's Windows notes — PowerShell as primary shell when Git Bash is absent — are platform plumbing we leave to the source.)
13 · Background Tasks

Background tasks keep long jobs off the critical path — the conversation never blocks

Say "run the full test suite in the background" and Claude starts it as task bg-1234 — then keeps working with you on something else. When the suite finishes, a 📢 notification lands in the conversation: 245 passed, 3 failed. Test suites, builds, migrations, deploys, analysis — anything long-running.

/task list           # all tasks + progress
/task status bg-1234 # progress + ETA
/task show bg-1234   # live output
/task cancel bg-1234 # stop it

Tuning

{
  "backgroundTasks": {
    "enabled": true,
    "maxConcurrentTasks": 5,
    "notifyOnCompletion": true,
    "autoCleanup": true
  }
}
The parallel-development pattern: build in one task, linter in a second, implement a feature in the foreground — three workstreams, one session. Just don't start more concurrent tasks than you can triage when they all report back.
14 · Monitor

Monitor replaces polling: zero tokens while quiet, instant reaction when a line matches

Polling with /loop or sleep burns a full API round-trip every cycle, whether or not anything changed. The Monitor tool (v2.1.98) attaches to any command's stdout — each matching line becomes an event that wakes the session. Silent in between, immediate when it fires.

Stream filter — continuous source

tail -f /var/log/app.log \
  | grep --line-buffered "ERROR"

"Start my dev server and monitor it for errors": server runs as a background task, the filter watches the log, and on the first ERROR|FATAL line Claude wakes, reads it, and reacts — restart, fix, or escalate.

Poll-and-emit — no native stream

last=$(date -u +%Y-%m-%dT%H:%M:%SZ)
while true; do
  gh api "repos/o/r/issues/123/comments?since=$last" || true
  last=$(date -u +%Y-%m-%dT%H:%M:%SZ)
  sleep 30
done

For APIs and databases: check periodically, emit output only when something changed.

The #1 way Monitor breaks: piping into grep without --line-buffered. grep buffers stdout in 4KB chunks — on a low-traffic stream that delays events by minutes. Filter seems silent? Check that flag first.
15 · Dynamic Workflows

Dynamic workflows fan one task out to hundreds of subagents — deterministically

New in v2.1.154. Where a single agent holds one context window, a workflow decomposes a task across tens to hundreds of background subagents and recombines their results — fan-out, pipelines, and parallel stages encoded in a script Claude authors, not left to the model's improvisation.

Coverage

Audit or review across many files and dimensions in parallel — every file in src/, every angle.

Confidence

Generate independent perspectives, then adversarially verify findings before committing.

Scale

Migrations, broad sweeps, research that no single context window can hold.

  • Launch: ask for one — "run a workflow to review every file in src/" · View: /workflows shows runs with live progress
  • ultracode in the /effort menu turns this on for the session; as of v2.1.160 the trigger keyword is ultracode — the bare word "workflow" no longer triggers a run
For a one-off task you already understand, a single agent or a direct edit is still the right tool — workflows pay off when the work fans out. They build on the subagent model from Chapter 4.
16 · Scheduled Tasks

Scheduled tasks live and die with the session — /schedule moves them to the cloud

Run prompts on a recurring interval or as one-time reminders: /loop 5m check if the deployment finished, "remind me at 3pm to push the release branch". Natural language or 5-field cron both work. Since v2.1.72; marketed as "Routines" on claude.com — same feature, the CLI command stays /schedule.

CronCreate / CronList / CronDeleteThe managing tools — since v2.1.136 CronList shows each task's prompt body for auditing
limits50 tasks per session · recurring auto-expire after 3 days
jitterRecurring: up to 10% of interval (max 15 min) · one-shot: up to 90 s
missed firesNo catch-up — tasks only fire while Claude Code is running
disableCLAUDE_CODE_DISABLE_CRON=1

Local vs cloud

  • Local (/loop, CronCreate): session-scoped, not persisted across restarts
  • Cloud (/schedule): runs on Anthropic infrastructure, persists across restarts, no local Claude Code needed — /schedule daily at 9am run the test suite

v2.1.139 gotcha: cloud /schedule is silently unavailable when ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, or apiKeyHelper is set — even if you're also logged in with claude.ai. Same gate hits Remote Control and the other claude.ai-bridged surfaces (Part 2). Local CronCreate is unaffected.

The decision rule: session-scoped chores → /loop; anything that must survive a restart → /schedule, CI/CD, or Desktop App scheduled tasks.
17 · Headless Mode

claude -p turns the agent into a Unix tool — pipe in, JSON out, CI/CD ready

Print mode (claude -p) runs Claude Code without interactive input — the non-interactive mode that replaced the older --headless flag. It's the building block for scripts, batch processing, and pipelines.

claude -p "Run all tests"

# pipe content in
cat error.log | claude -p "Analyze these errors"

# structured output + schema
claude -p --output-format json "Analyze code quality"
claude -p --json-schema '{"type":"object",…}' "find bugs"

# guardrails for automation
claude -p --max-turns 5 "refactor this module"
claude -p --no-session-persistence "one-off analysis"

The CI/CD shape (GitHub Actions)

# .github/workflows/code-review.yml
on: [pull_request]
steps:
  - uses: actions/checkout@v4
  - run: npm install -g @anthropic-ai/claude-code
  - env:
      ANTHROPIC_API_KEY: ${{ secrets.… }}
    run: |
      claude -p --output-format json --max-turns 3 \
        "Review this PR for quality, security,
         performance, coverage" > review.json
  # then post review.json as a PR comment
The pattern: cap the turns, demand JSON, persist nothing — a headless run should be bounded, parseable, and stateless. Chapter 10 goes deep on the CLI and output formats.
18 · Sandboxing

Sandboxing is the OS-level second layer — contain what permissions merely vet

Permission rules decide whether a command runs; sandboxing decides what it can touch when it does. Bash commands execute with OS-level filesystem and network isolation — complementary to permission rules, defense in depth. Enable with /sandbox or claude --sandbox.

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "filesystem": {
      "allowWrite": ["/Users/me/project"],
      "allowRead": ["/Users/me/project", "/usr/local/lib"],
      "denyRead":  ["/Users/me/.ssh", "/Users/me/.aws"]
    },
    "enableWeakerNetworkIsolation": true
  }
}

Network rules

{
  "network": {
    "allowedDomains": ["*.example.com"],
    "deniedDomains":  ["evil.example.com"]
  }
}

deniedDomains (v2.1.113) wins over a broad wildcard — the whole domain passes, the named host stays blocked. On macOS full network isolation isn't available — use enableWeakerNetworkIsolation. Linux/WSL can point at custom bwrapPath / socatPath binaries (v2.1.133).

When to reach for it: untrusted or generated code, protecting files outside the project, throttling network during automated runs — exactly the situations the autonomy features in this deck create.
19 · Git Worktrees

Worktrees give every parallel effort its own working copy — no stash, no switch

claude --worktree (or -w) starts the session in an isolated git worktree at <repo>/.claude/worktrees/<name> — feature work proceeds while main stays untouched, and if no changes are made the worktree auto-cleans on session end.

worktree.baseRefv2.1.133 — "fresh" (default) branches from origin/<default>, ignoring unpushed commits (reverting v2.1.128's behavior); "head" preserves them
worktree.bgIsolationv2.1.143 — background sessions get their own worktree by default; "none" lets them edit the live working copy (loses the isolation safety net)
worktree.sparsePathsSparse-checkout for monorepos — less disk, faster startup

Tools and hooks

  • EnterWorktree — enter one; since v2.1.157 it can switch between Claude-managed worktrees mid-session
  • ExitWorktree — exit and clean up
  • WorktreeCreate / WorktreeRemove — hook events on create and remove
  • Since v2.1.157 finished worktrees are left unlocked, so git worktree remove/prune can collect them
This is the isolation primitive under the whole deck: background sessions, parallel experiments, and test runs each get a disposable working copy — concurrency without merge chaos in your live tree.
20 · Recap

Autonomy is earned in layers — plan it, gate it, watch it, contain it

Plan it: planning mode drafts before it builds (yes / no / modify), opusplan splits drafting from execution, Ultraplan moves the drafting to the cloud, and extended thinking's effort ladder buys deeper reasoning when the decision deserves it. Gate it: six permission modes ladder from read-only plan to unchecked bypassPermissions, with auto mode's classifier in between — your rules first, cheap lanes pre-cleared, fallback to you after 3 consecutive or 20 total blocks. Watch it: background tasks keep long jobs off the critical path, Monitor wakes the session on a matching line instead of burning poll cycles, dynamic workflows fan out to hundreds of subagents, scheduled tasks recur locally or persist in the cloud, and claude -p runs it all headless in CI. Contain it: sandboxing fences the filesystem and network at the OS level, and worktrees give every parallel effort a disposable working copy.

Try it now: /plan something real, approve it, then press Shift+Tab and read the mode ladder you're climbing. Part 2 — Sessions, Surfaces & Settings — covers session management, interactive features, voice, Chrome, remote control, web and desktop, managed settings, configuration, and agent teams.
Sid Dani