freno-dev/marketing/approved/agent-run-without-asking/copy.md

Should you let your coding agent run without asking permission?

Status: approved — sponsor fact-check passed 2026-11-05 (FRE-199 pair 2 fact-check card, verdict: "Approve both — move to approved/"). Not published; a human places it on nook.freno.me from approved/. Internal target: Mon 2026-11-09, met four days early. This page never names a product of ours and never names a competitor.

You can — and the honest answer is that "should" is not one decision but two: what you are letting it do, and what happens when it does the wrong thing. Every operator who runs agents unattended converges on the same split — a free hand on what git can undo, a confirmation on what it can't — and the agent's own permission modes exist to draw that line somewhere you choose, not somewhere a flag chooses for you.

The mechanism: a spectrum, not a switch

Claude Code's permission modes form a ladder from "ask for everything" to "ask for almost nothing", and each rung has a documented meaning:

• default prompts on the first use of each tool.
• acceptEdits auto-accepts file edits and common filesystem commands (mkdir, touch, mv, cp) inside the working directory.
• plan reads files and runs read-only shell commands but does not edit your source files — the agent explores, you approve the plan.
• auto runs without routine prompts; before actions such as shell commands and network requests run, a background classifier checks that they align with your request.
• bypassPermissions skips permission prompts, except for actions no mode auto-approves.

Two documented facts should shape where you stop on that ladder. First, the docs' own warning on the top rung: in bypassPermissions mode Claude Code skips prompts — including for writes to protected paths such as .git — and the mode belongs "in isolated environments like containers or VMs where Claude Code can't cause damage". Second, enforcement is real, not advisory: the docs state plainly that "permission rules are enforced by Claude Code, not by the model" — a CLAUDE.md instruction asking nicely for permission changes nothing.

What to check or do

1. Decide by blast radius, not by annoyance. The question "how do I get fewer prompts?" tempts a jump to the top of the ladder. The better question: which of this agent's actions would be undoable if wrong? Edits inside a git worktree are; rm -rf on the wrong path, a pushed commit, and a message sent to a third party are not.
2. Move down the ladder one rung at a time. acceptEdits in a worktree covers most of the prompt volume with the undo still in reach. If you consider auto or bypassPermissions, the docs' own container-or-VM condition is the bar: isolation first, autonomy second.
3. Write the rules instead of trusting the mode. Rules are evaluated in order — deny, then ask, then allow — and the first match wins, so a broad deny holds even against a narrower allow. Bash(git commit *) allowed with Bash(git push *) denied is a policy the agent cannot talk its way around.
4. Know what the rules do not cover. A Bash rule matches the command text Claude writes, and the docs are explicit that this "isn't a security boundary around the program" — the same binary invoked by another path is not matched. For filesystem and network enforcement that does not depend on command text, the docs point at sandboxing.
5. Use hooks as the programmable layer. A PreToolUse hook sees every tool call before it runs and can return a deny decision — the reference builds one that blocks rm -rf. A silent hook does not approve anything; the call just continues through the normal permission flow.
6. Leave the failure path a way to reach you. An unattended run that hits a prompt nobody sees stops silently — that is the failure mode of unattended work, not of permissions. Whatever mode you pick, wire the "waiting on you" event somewhere you will actually notice.

One next step: write down the three actions your agent takes that you could not undo, and put them in deny or ask rules today. Whatever mode you run above them, those three now require a human — which is the whole point of the ladder.

---

Fact-check table (not part of the page)

Every technical claim above, with its primary source. Claims about Claude Code's behaviour come from its own documentation, re-read 2026-11-05.

#	Claim in the page	Source
1	Mode meanings: default prompts on first use; acceptEdits auto-accepts file edits and common filesystem commands (mkdir, touch, mv, cp) in the working directory; plan reads files and runs read-only shell commands but doesn't edit source; auto runs without routine prompts with a background classifier checking alignment; bypassPermissions skips prompts except actions no mode auto-approves	Claude Code permissions doc — https://code.claude.com/docs/en/permissions (Permission modes table)
2	Docs' warning: in bypassPermissions mode Claude Code skips prompts including for writes to protected paths such as .git; "Only use this mode in isolated environments like containers or VMs where Claude Code can't cause damage"	same permissions doc (warning under the modes table)
3	"Permission rules are enforced by Claude Code, not by the model"	same permissions doc (note under Manage permissions)
4	Rules evaluated in order deny → ask → allow; first match wins; a broad deny holds against a narrower allow	same permissions doc (Manage permissions)
5	A Bash rule matches the command text Claude writes and "isn't a security boundary around the program" (Bash(curl *) doesn't stop /usr/bin/curl …); for filesystem/network enforcement independent of command text the docs point at sandboxing	same permissions doc (What a Bash rule doesn't match)
6	A PreToolUse hook fires before a tool call executes, can block it, and can return a permissionDecision of "deny"; the reference builds a hook that blocks rm -rf; a silent hook does not approve — the call continues through the normal permission flow	Claude Code hooks reference — https://code.claude.com/docs/en/hooks (PreToolUse decision control walkthrough)
7	Undo-split practice ("free hand on what git can undo, confirmation on what it can't")	r/ClaudeCode 1xkoz06 (2026-10-31), commenter's described practice, logged in drafts/listening.md Scan 3 addendum; also r/ClaudeCode 1xexhwf commenters (VM, worktrees, blast-radius split). Described as operator practice, not a rule.
8	An unattended run that hits a prompt nobody sees stops silently	r/ClaudeCode 1xipsk0 (2026-10-29), commenter: "A run started from launchd or a background service can hit a prompt that no one will ever see", logged in drafts/listening.md Scan 2.
9	The trust asymmetry: comfortable with a model writing code, "considerably less comfortable giving an autonomous agent broad access to my development environment"	r/ClaudeCode 1xk8imc (2026-10-31, "Has anyone built a safe, autonomous coding workflow…?", 43 comments), OP's words, logged in drafts/listening.md Scan 4.
10	The operator's own safety menu: "committing before every run? containers? --dangerously-skip-permissions and hoping?"	r/ClaudeAI 1xk277d (2026-10-31, "How often has a coding agent done something you had to undo?"), OP's words, logged in drafts/listening.md Scan 4. Quoted as the question's shape, not as guidance.

Ban compliance: no product of ours named · no competitor named · no handles · no superlatives · no benchmark numbers · no invented testimonials · no price · no roadmap dates. The docs' container/VM warning is quoted as the agent's own documentation, not as our policy.