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.
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.
Plan & reason
Planning mode, Ultraplan cloud drafting, extended thinking effort levels.
Permission control
Six permission modes, plus auto mode's background safety classifier.
Automation
Background tasks, the Monitor tool, dynamic workflows, scheduled tasks, headless CI.
Isolation
OS-level sandboxing and git worktrees keep autonomous work fenced in.
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
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 plan | CLI flag at launch |
| "defaultMode": "plan" | Settings — make plan the default under permissions |
| Shift+Tab · Alt+M | Cycle 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
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.
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
| ◇ ultraplan | Researching + drafting |
| ◇ needs your input | Clarifying question waiting |
| ◆ ultraplan ready | Review 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.
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 |
| xhigh | Opus 4.8 and 4.7 only (the 4.7 default); falls back to high elsewhere |
| max | All four effort models, session-only |
| Haiku 4.5 | No 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
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"
Four gates decide each action — and control returns to you when "no" piles up
The defaults block the catastrophic and allow the local — extend them, don't replace them
Blocked by default
| curl | bash | Pipe-to-shell installs |
| keys over network | Sending sensitive data externally |
| prod deploys · IAM | Production targets, permission changes |
| rm -rf · force push | Mass 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.
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
| baseline | Read / Glob / Grep / Agent / WebSearch, plus git status·log·diff, ls, cat, find… |
| --include-edits | Edit / Write / NotebookEdit |
| --include-tests | pytest, cargo test, go test, make |
| --include-git-write | add, commit, checkout, stash, tag |
| --include-packages | npm ci/install, pip install |
| --include-gh-write/read | gh pr create · gh pr/issue/repo view |
Six modes form a ladder — each step changes what runs without asking, and who gates it
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.
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
}
}
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.
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
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 / CronDelete | The managing tools — since v2.1.136 CronList shows each task's prompt body for auditing |
| limits | 50 tasks per session · recurring auto-expire after 3 days |
| jitter | Recurring: up to 10% of interval (max 15 min) · one-shot: up to 90 s |
| missed fires | No catch-up — tasks only fire while Claude Code is running |
| disable | CLAUDE_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.
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
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).
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.baseRef | v2.1.133 — "fresh" (default) branches from origin/<default>, ignoring unpushed commits (reverting v2.1.128's behavior); "head" preserves them |
| worktree.bgIsolation | v2.1.143 — background sessions get their own worktree by default; "none" lets them edit the live working copy (loses the isolation safety net) |
| worktree.sparsePaths | Sparse-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
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.