marketing: FRE-199 fact-check verdict applied — second pair drafts/ → approved/

Sponsor fact-check card (FRE-199, interaction a7cba232) answered 2026-11-05
20:21Z: 'Approve both — move to approved/'. Status blockquotes updated to
record the verdict and the date; page bodies untouched.

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

@@ -0,0 +1,98 @@
+# 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.