Run hands-off with auto mode, and when to reach for bypass

Some jobs are too long to sit through. Take the course’s payments service (a small Express and TypeScript app) where every route in src/index.ts needs migrating to a new error-handling helper, a change that reaches the payment code under src/payments/ and its tests, with a test run after each step, and you want to start it and go to a meeting. This is a different ask from approving edits faster. acceptEdits mode (the permission mode that auto-applies file edits but still prompts for commands) assumed you were there, reviewing diffs as they landed. Now you want nobody in the room.

The naive way to get there is to throw away all the prompts. The right way is to see that “hands-off” and “no safety checks” are two different things, and to pick the mode that gives you the first without the second.

Auto mode: hands-off with a net

Auto mode is the permission mode where most actions run without asking and a background classifier reviews each one, blocking the unsafe ones. On current versions it is also the starting mode for a plain claude launch in the terminal, which is why this course’s walkthroughs pin --permission-mode default instead; the default-prompt lesson lists which versions and exceptions. Availability, labels, and administrator controls vary by release and account: Team and Enterprise administrators can disable it with the permissions.disableAutoMode setting, and if it does not appear in your Shift+Tab cycle (Shift+Tab flips Claude Code between permission modes mid-session), check the current permission-modes docs before assuming your plan is unsupported.

The net is good, not perfect. Anthropic is explicit, in the permission-modes docs, that auto mode reduces risk rather than guaranteeing safety, so it is for work where you trust the general direction, not a licence to walk away from something irreversible. Two things make the difference before you leave:

1. Write a task contract. Stay inside this checkout; do not read .env or secrets/; do not commit, push, deploy, delete data, or call external services; run the existing tests; leave a summary plus the final diff.
2. Back the boundaries that must hold with rules. A boundary stated in conversation guides the run; it is not a durable permission rule. For a file the agent must never read, write a deny rule, which holds in every mode. For a command it may always run, an allow rule keeps the classifier from being the only thing standing between the run and a stall.

Ask for test output and a clear failure state in the summary so a reviewer can reconstruct what happened. Hooks, explicit rules, tool limitations, and provider policy still apply during the run.

Bypass: the net removed - containers only

There is a mode that removes the normal permission prompts: bypassPermissions, started with the --dangerously-skip-permissions flag and often called “YOLO mode” in the wild. It skips permission checks and the prompts for protected paths (.git, .claude, shell startup files, .mcp.json), so it offers no reliable protection against prompt injection: a malicious instruction hidden in a file the agent reads can influence actions on the machine. Deny rules still block, and a few explicit safeguards may still stop a call, but do not treat any of that as a security boundary.

So bypass has exactly one legitimate home: an isolated environment that cannot hurt anything - a container, a VM, or a dev container with no access to your real filesystem or network. Inside that blast radius, full speed with no prompts is fine, because the worst case is a wrecked throwaway box. Pointed at your actual working machine, it is the single most dangerous setting in the tool. The sandbox setup exists precisely so that “no prompts” and “no blast radius” go together.

The rule of thumb writes itself: auto mode to go hands-off on your real machine; bypass only inside a sandbox that does not matter. Reaching for bypass to skip prompts on your laptop is choosing the one mode with no net, to save the few seconds auto mode would have cost you.

dontAsk: unattended without surprises

There is also a stricter sibling built for unattended runs: dontAsk, the permission mode that denies any call that would otherwise prompt and runs only what needs no approval or has an allow rule. It never appears in the Shift+Tab cycle; you set it with --permission-mode dontAsk, and it is the posture the automation chapter builds on for headless runs and CI, where zero interactivity and zero surprises are the point.

The dial, end to end

Step back and look at the full range on one codebase: default (every consequential action prompts) for sensitive work, acceptEdits for a mechanical rename, allow rules for the test loop, deny rules for secrets, and auto for an unattended batch. That is one dial, set deliberately per task. Set the authority to match the work, then change it when the work changes.

One rung got skipped on the way up: plan mode, the tight setting where the agent researches and proposes but changes nothing. Making the agent think before it builds is a discipline of its own, and it is the whole of the planning chapter.