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

# Should you let your coding agent run without asking permission?

> **Status: draft — awaiting sponsor fact-check** (FRE-199 pair 2, internal
> target Mon 2026-11-09). 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.