0137703341
B1 (agent-waiting-on-permission): body said 'allow / ask / deny' — inverted vs the permissions doc's deny → ask → allow. Fixed; fact-check row 3 was already correct and now matches the body. B2 (agent-run-without-asking): dropped the 'Bash(git commit *) allowed with Bash(git push *) denied is a policy the agent cannot talk its way around' example — the docs' own 'What a Bash rule doesn't match' table names Bash(git push *) as not stopping git -C . push origin main and friends. Sentence narrowed to the precedence claim, with a pointer to step 4's caveat. N1 (agent-done-signal): the osascript desktop-notification example is in the hooks guide (code.claude.com/docs/en/hooks-guide), not the hooks reference. Body and fact-check row 4 fixed. Pair-1 citations standardised from docs.anthropic.com to code.claude.com per the review's optional note. Each page's status blockquote records the revision.
87 lines
5.6 KiB
Markdown
87 lines
5.6 KiB
Markdown
# Why is my coding agent sitting on a permission prompt?
|
|
|
|
> **Status: approved — sponsor fact-check passed 2026-11-05** (FRE-199 fact-check
|
|
> card, verdict: "Approve both — move to approved/"). Not published; a human
|
|
> places it on nook.freno.me from `approved/`.
|
|
> This page never names a product of ours and never names a competitor.
|
|
> Internal target: second page of the FRE-199 pair, Fri 2026-11-07.
|
|
> CTO review 2026-11-05: changes requested and applied — rule precedence
|
|
> corrected to deny / ask / allow (body previously read allow / ask / deny,
|
|
> contradicting the fact-check table and the source); pair-1 citations
|
|
> standardised to code.claude.com.
|
|
|
|
Because it tried to do something its permission settings don't allow, and the
|
|
default is to wait — indefinitely and quietly — for you. The prompt is not the
|
|
expensive part; the hour you spent not knowing it was waiting is. The way out is
|
|
not to approve faster, it's to make the prompts rare and the waiting visible.
|
|
|
|
## The mechanism
|
|
|
|
Claude Code's permission system decides, per tool call, whether to run, refuse,
|
|
or stop and ask. In its `default` mode, it prompts for permission on the first
|
|
use of each tool. Modes are set with `defaultMode` in the settings files, and a
|
|
session's rules come from deny / ask / allow lists evaluated in that order —
|
|
the first match wins.
|
|
|
|
You can see the whole rule set at any time with `/permissions`, which lists
|
|
every permission rule and the settings file each one came from. Rules can name
|
|
a specific use — `Bash(npm run build)` matches exactly that command — or a
|
|
wildcard, like `Bash(git log *)`.
|
|
|
|
So the prompt you came back to an hour later is not a malfunction. It is the
|
|
system working as configured, on a call your rules never covered — and the
|
|
"waiting" state being invisible is what turned ten seconds of approval into a
|
|
lost hour.
|
|
|
|
## What to check or do
|
|
|
|
1. **Read the prompt before automating it away.** It names the tool and the
|
|
input. The right response to "it keeps asking" is usually a rule, not a
|
|
wider mode.
|
|
2. **Allowlist the undoable, prompt on the irreversible.** Reads, tests, and
|
|
status commands are safe to allow — `git` is the undo for edits. Anything
|
|
that reaches another person or another system — network calls, deletes,
|
|
deploys — is worth keeping on ask. Rule syntax is in the permission docs;
|
|
`/permissions` shows what you already have.
|
|
3. **Consider `acceptEdits` before anything broader.** It auto-accepts file
|
|
edits and common filesystem commands inside the working directory. That is
|
|
usually the difference between ten prompts a session and two — without
|
|
handing over network or delete.
|
|
4. **Bound the blast radius instead of removing the gate.** If you do widen
|
|
what runs unattended, do it where a mistake is recoverable: a worktree per
|
|
task, commits pushed early, nothing irreversible in reach. Operators who run
|
|
agents unattended describe exactly this split — free hand on what git can
|
|
undo, confirmation on what it can't.
|
|
5. **Make the wait visible.** Claude Code fires a `Notification` hook when it
|
|
sends a notification, and a permission prompt is one — the payload carries a
|
|
`notification_type` of `permission_prompt`. A hook on that event, wired to a
|
|
desktop notification you'd see from another window, turns the silent wait
|
|
back into a ten-second approval.
|
|
|
|
One next step: run `/permissions` today and add allow rules for the three
|
|
commands you find yourself approving most. The prompts that remain will be the
|
|
ones that deserve a read.
|
|
|
|
---
|
|
|
|
## 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 | In `default` mode Claude Code "prompts for permission on first use of each tool" | Claude Code permissions doc — https://code.claude.com/docs/en/permissions (Permission modes table) |
|
|
| 2 | `defaultMode` in settings files sets the default mode for new sessions | same permissions doc (Permission modes section) |
|
|
| 3 | Rules are evaluated deny → ask → allow, first match wins | same permissions doc (Permission rule syntax) |
|
|
| 4 | `/permissions` lists all permission rules and the settings.json each comes from | same permissions doc (Manage permissions) |
|
|
| 5 | `Bash(npm run build)` matches the exact command; `Bash(git log *)` wildcard form | same permissions doc (Use specifiers for fine-grained control) |
|
|
| 6 | `acceptEdits` "automatically accepts file edits and common filesystem commands such as mkdir, touch, mv, cp for paths in the working directory" | same permissions doc (Permission modes table) |
|
|
| 7 | A `Notification` hook fires when Claude Code sends a notification; permission prompts carry `notification_type: "permission_prompt"` and a message like "Claude needs your permission" | Claude Code hooks reference — https://code.claude.com/docs/en/hooks (Notification event) |
|
|
| 8 | Undo-split practice ("free hand on what git can undo, confirmation on what it can't") | r/ClaudeCode 1xkoz06 (2026-10-31, u/tomm3hshipp thread), commenter's described practice, logged in `drafts/listening.md` Scan 3 addendum. Described as one operator's approach, not a rule. |
|
|
| 9 | The 55-minutes-lost framing | r/ClaudeAI 1xhbc71 (2026-10-28): "coming back an hour later to find it's been sitting on a permission prompt for 55 minutes". Used as the problem's shape, not quoted as a person. |
|
|
|
|
**Ban compliance:** no product of ours named · no competitor named · no
|
|
superlatives · no benchmark numbers · no invented testimonials · no price · no
|
|
roadmap dates.
|