You set Claude Code on a multi-step refactor, walk away for a coffee, and come back to find it parked on step two, waiting for permission to run mkdir. The agent did not crash. It did not run out of context. It stopped to ask "should I continue?" and is now politely waiting for your acknowledgment. Here is what is actually firing those prompts, why they cluster on the work you most want to leave running, and what an auto-nudge layer changes about the round trip.
TL;DR: Claude Code’s permission gate is doing its job — not “losing nerve.” Default allow-lists force per-tool approvals, so multi-step work becomes a stack of “should I continue?” prompts. Pre-approving everything or --dangerously-skip-permissions has real blast radius. A policy-driven auto-nudge leaves the gate on for destructive tools and skips the safe long tail (Read / Grep / boring Bash).
The permission model that produces the prompt
Claude Code's permission system is opt-in by default. Anything that touches the file system, executes a shell command, or hits a network endpoint requires explicit allow-list entry before the agent runs it without asking. Anthropic's published model lists three buckets:
| Bucket | Who decides | What it feels like |
|---|---|---|
| Always allowed | Agent | Smooth, no pause |
| Approval per use | You | “Should I continue?” / allow prompt |
| Blocked | Policy | Hard stop |
The "should I continue?" prompt is the user-decides bucket firing on a command the agent has not been told it can run. The default ruleset is conservative: bare Bash requires approval per invocation. So does Write on any path that has not been pre-cleared. So does any MCP tool that has not been added to the allow-list.
Not a crash. What looks like the agent losing nerve is usually the gate doing its job. The agent still has a plan — the gate is asking whether each step should execute.
Why the prompts cluster on the worst possible moments
If the gate fired uniformly, interruptions would be tolerable. They do not fire uniformly. They cluster.
- Tool variation. A refactor that touches twelve files uses
Edittwelve times — twelve approvals when paths are not allow-listed. ThenBashfor tests. ThenWritefor a new config. The gate questions per tool surface per argument shape, not per “task.” - Weak argument generalization. Allow-lists can match exact commands (
Bash(git status)) but not every near-variant (Bash(git status --porcelain)). Real refactors generate a long tail of variants. - Stop hooks. Some setups intercept end-of-turn on purpose. Combined with the permission gate, sessions stop far more often than expected.
- Auto-compact boundaries. After compact, resume often emits a fresh “ready to continue?” cue because replan is a new planning surface.
The result: a session that runs unattended for fifteen minutes, then sits idle for forty waiting for a human eye.
What developers reach for first
The community has converged on a small set of workarounds, in order of escalation.
| Move | Upside | Downside |
|---|---|---|
Pre-approve in settings.local.json | Official, per-project | Does not survive new argument shapes; list grows forever |
--dangerously-skip-permissions | Zero prompts | Full blast radius — including horror stories like destructive writes with no gate |
| Babysit the session | Safe in theory | Most expensive option in human time |
| Transcript “yes” gists | Right shape | Fragile — JSONL format drifts |
Pre-approve everything in settings.local.json. The official move. Add tool names and argument patterns to the project's permissions.allow list. This works for stable commands but does not survive new argument shapes, and the file gets long fast.
Use the --dangerously-skip-permissions flag. Anthropic's nuclear option. Works. Also occasionally produces the horror stories that fuel issue threads where Claude deleted the user's Desktop folder because nothing was there to stop it.
Claude Code's default behaviour is to ask for permission for every command it wants to run. This makes sense from a security perspective, but it becomes a major workflow killer when you're trying to automate longer tasks.
That is from ksred's analysis of the skip-permissions flag. The same piece documents the failure mode: a developer setting Claude Code on a config-update task, walking away, returning to find Claude had wiped the live config file by writing blank defaults to it because no backup step existed and no gate stopped the destructive write.
Babysit the session. A real choice, and the worst one in aggregate. A senior developer at $150/hour, idle for an hour waiting on prompts, has spent more on the babysitting than a month of Claude Max.
Write a watchdog script. A growing pattern: watch the transcript JSONL for “should I continue?” and inject “yes.” Community gists exist. They are fragile. The transcript format has changed twice in six months.
What an auto-nudge layer actually does
The fragile-gist approach has the right shape but the wrong substrate. The shape: detect when the agent is parked, decide whether the parking is safe to skip past, inject the resume signal. The wrong substrate: parsing a private transcript format that changes on every Claude Code release.
A workable auto-nudge layer attaches to the request stream, not the editor file. It sees the API exchange, recognizes parking patterns, and acts. The API response shape is more durable than editor-private JSONL.
The decision of whether to nudge is policy-driven, not blanket:
- Tool-class safety. Read tools (Read, Grep, Glob, network GETs) get nudged automatically. Write/Edit/Bash get a configurable policy per project.
- Destructive command detection. Bash shapes like
rm -rf,git reset --hard,curl | shnever nudge — they sit until a human approves. - Session boundaries. New sessions start stricter; consistent allow-pattern behavior can relax checks over time.
- Audit log. Every auto-nudge writes a local line. Reviewable. Greppable. “What did the nudge layer allow yesterday?”
Outcome: a session that runs unattended for hours on read-heavy work without losing the safety story on write-heavy work. It stops asking about git status and ls. It still stops on rm -rf node_modules.
The cost the layer recovers
The babysitting bill is concrete. A multi-step refactor that takes the agent forty minutes of compute can span two and a half hours of human time when twenty permission prompts arrive at five-minute intervals.
There is a second-order recovery: prompts every five minutes also kill the cognitive flow needed for parallel work. You cannot fully context-switch to a design doc if the next prompt might land any second.
An auto-nudge layer plus a real notification (push, desktop, Slack) restores the asymmetry: agent runs unattended; you get paged only when something deserves judgment.
Frequently asked questions
Why does Claude Code ask "should I continue?" between obviously related steps?
Because the permission gate does not know they are related. From the gate's perspective, each tool invocation is independent: a fresh Bash command, a fresh Edit on a path it has not seen, a fresh Write to a directory not yet in the allow-list. The agent's task plan is one thing; the gate sees each tool call as another.
Is --dangerously-skip-permissions safe to use?
It depends on blast radius. Sandboxed throwaway work: risk is lower, productivity is high. Real production data, credentials, or your home directory: the flag is genuinely dangerous. The GH #30700 Desktop-deletion thread is the cautionary tale. Use it only where the blast radius is contained.
How does an auto-nudge layer differ from --dangerously-skip-permissions?
The skip-permissions flag disables the gate entirely. An auto-nudge layer leaves the gate intact for dangerous commands and skips only the safe long tail. Blast radius stays bounded by allow-list logic plus a destructive-shape detector.
Will an auto-nudge layer cause Claude Code to ignore my explicit deny rules?
A working implementation honors permissions.deny as the floor. The layer only acts on commands that would have been allowed if you had answered “yes.” Denied commands stay denied. Ambiguous commands stay paused.
Can I see what the nudge layer decided while I was away?
A working implementation writes an audit log per session: tool, arguments, timestamp, rule. Grep when you return. Unexpected decisions should tighten auto-allow scope next run.
Related reading
- Claude Code Auto-Compact: Why the Summary Loses Your Work — another reason sessions pause to re-ask for direction.
- Paying Opus, Served Haiku: Silent Downgrades in Claude Code — if the agent also asks questions it should not need to ask.
- The $6,000 Overnight Claude Code Loop: How Bills Snowball — what happens when “just keep going” runs without a safety story.
What developers are reporting
Developers have asked Anthropic for this directly. GitHub issue #18980 requests a "Continue after limit is reset" option because "setting a timer and waiting to type continue is not very efficient" — especially across several open sessions. Auto-resume is that feature, today.
Closing
The permission gate exists for a reason — the GH #30700 thread is what happens when nothing checks the agent's hand on the wheel. The cost of those defaults, paid in senior-developer attention, is large enough to fund a layer that pulls "should I continue?" prompts out of the read-heavy long tail without softening the safety story on the write-heavy short list. The watchdog we ship is the version we built for our own sessions, and the version we put in front of customers running Claude Code unattended.
If you want to run it against a long unattended session of your own, the 14-day Premium Trial is $0 today and you can cancel anytime before day 15 — it adds the watchdog, the audit log, and push notifications on top of the nudge layer. Not ready to put a card down? Install Power Claude Free instead: the 7-day free trial gives you full Pro access, no credit card.