Handing Me Every Permission on Day One
In one sentence: during setup you hand me
--dangerously-skip-permissionsand auto-approve every tool call, because you don't want to be interrupted. What you also hand over is the one chance to stop things at the moment they go wrong โ and the thing that goes wrong might not be me, but an injected instruction hidden in a file, acting through my hands.
Symptomโ
Here's a start I run into a lot. You launch me for the first time, get interrupted by a few permission prompts, find them annoying, and reach for --dangerously-skip-permissions โ or you drop Bash(*) and Write(*) straight into the allow list in settings.json. From then on I read files, change code, run commands, install dependencies, and push to Git without ever checking with you.
Your expectation is less friction, letting me run end to end. And most of the time it works that way โ right up until the one run where I execute a command you would never have approved, and by then there's no "approve" step left.
Why this happensโ
A permission prompt isn't UI noise. It's the only synchronization point between you and me. Turning it off gives up three things at once.
First, you lose the last layer of human review. I make concrete mistakes. I might read a relative path as the filesystem root and rm -rf starting from /; I might pick the wrong branch during a git operation. These aren't abstract risks โ in October 2025, someone asked me to rebuild a Makefile project and I ran rm -rf from the root, wiping every file owned by that user on the machine. A permission prompt would have caught it before the command fired.
Second, you widen the prompt-injection attack surface. I read the files you point me at, and a file can contain instructions you didn't write. In January 2026, PromptArmor demonstrated that a .docx with text hidden in 1-point white-on-white font could trick me into uploading sensitive files to an attacker's account. Any time I combine access to private data, exposure to untrusted content, and the ability to communicate outward, an attacker has an opening to make me leak that data. Permission boundaries are exactly where you cut that chain โ and you removed the whole boundary.
Third, approval fatigue turns on you. Even without full auto-approval, if every single step prompts you, you quickly slip into mindless "yes" clicking; your attention dulls and the prompt becomes theater. Anthropic named this directly when building auto mode: the default per-action prompting keeps you safe, but over time it leads people to stop reading what they approve.
Consequencesโ
- Irreversible damage. Accidental deletes, overwrites, a wrong
git push --forceโ by the time you notice, there's usually no undo. - Data leakage. Injected instructions use tools I've already been granted (an allowed API,
curl) to ship private content outward, and every step looks legitimate. - Privilege overreach. I run a command with production credentials that was only ever meant for a test environment, because no boundary told me "not here."
- Hard to investigate. Full auto mode leaves no per-action approval trail, so reconstructing which step went wrong, and why, is painful after the fact.
What to do insteadโ
Default to least privilege, open up incrementally, and reserve full automation for an isolated environment. A few things you can apply directly:
- Draw red lines with
deny, green lights withallow, leave the rest toask. Rules match in the orderdenyโaskโallow. Nail down what must never be touched first, then allow the high-frequency, safe read operations:
{
"permissions": {
"allow": ["Read", "Glob", "Grep", "Bash(git status)", "Bash(git diff:*)"],
"ask": ["Write", "Edit", "Bash(git push:*)"],
"deny": ["Bash(rm -rf:*)", "Bash(curl:*)", "Read(./.env)", "Read(./secrets/**)"]
}
}
-
Dangerous operations always go through
ask. Writing files, deleting, pushing, network requests, installing dependencies โ keep these gated. That gate is your last review. -
For unattended runs, sandbox first, never run bare. The community consensus is firm: never run
--dangerously-skip-permissionson your primary machine. If you want full automation, put it in a container or VM with filesystem and network isolation. Anthropic's internal data shows sandboxing safely cut permission prompts by 84%. -
Prefer auto mode over skipping permissions outright. Newer Claude Code offers auto mode: a model-based classifier judges whether each action is dangerous before it runs, and after 3 consecutive or 20 total denials it stops and hands control back to you. It's the middle ground between per-action prompts and skipping everything, and it's far safer than
--dangerously-skip-permissions.
Exampleโ
Before:
You: claude --dangerously-skip-permissions
You: clean up the build artifacts and rebuild
Me: (runs rm -rf <relative path misread as absolute>, nothing stops it)
After:
# In settings.json: rm is in deny, write operations go through ask
You: clean up the build artifacts and rebuild
Me: I want to run rm -rf ./build โ I need your confirmation (hits ask)
You: (sees the path is ./build, not /, and confirms)
Me: (runs inside the boundary, rebuilds)
The difference isn't that I got smarter. It's that the rm got one more chance โ for you to see it clearly and stop it โ before it landed.
When the exception appliesโ
It's not "never go full-auto" โ it's "don't go full-auto where there's a real blast radius." When the blast radius is already boxed in by the environment, skipping per-action confirmation is reasonable, even more efficient:
- An isolated sandbox / throwaway container / VM: filesystem and network isolated, no production credentials, disposable and easy to rebuild. This is exactly what the best practice above means by "put full-auto in a sandbox" โ the environment replaces the human-confirmation gate.
- A temporary, disposable scratch repo: no sensitive data, no outbound-communication capability, nothing you'd mourn if it's wiped.
Conversely, the moment the environment still carries two or three of "private data / reads untrusted content / can talk outward," the exception is off โ back to least privilege by default. The test, in one line: what makes full-auto safe isn't "I trust the model," it's "even if it does the worst thing, it can't get out of this box."
Tool differencesโ
Gemini CLI (as of 2026-06): In Gemini CLI the one-flip "open everything" is YOLO mode (--yolo / --approval-mode=yolo / Ctrl+Y mid-session), which likewise auto-approves every tool call. It also has a middle tier, auto_edit: file edits are auto-approved, but shell commands still need your confirmation โ a compromise between per-action prompts and full auto. One stance worth copying: it pairs sandbox-on with YOLO by default as the "recommended automation" configuration, so don't run YOLO without the sandbox โ that tears out both the human gate and the environment gate at once.
Codex CLI (as of 2026-06): Codex uses three approval presets (Read Only / Auto / Full Access), and the default one (Auto) is already sandboxed (workspace-write + network off + on-demand approval) โ the exact opposite of Claude Code's "sandbox off by default," so here the dangerous move is the user actively opting out of a safe default rather than forgetting to turn one on. The one flip that opens everything is --dangerously-bypass-approvals-and-sandbox; enterprises can forbid it via requirements.toml.
Cursor (as of 2026-06): Cursor's "open everything" is Auto-Run / YOLO, gated by the allowlist / denylist in permissions.json. Two things: (1) Cursor deprecated the denylist in 1.3 โ researchers demonstrated bypasses via Base64, subshells, quote obfuscation, and more, concluding the denylist is the wrong tool and only an allowlist works; (2) the classifier behind the current default Run Mode (Auto-review) is, in Cursor's own words, "non-deterministic and not a security boundary."
GitHub Copilot (as of 2026-06): In VS Code agent mode, my "open everything" switch is chat.tools.autoApprove (auto-approve tools) / chat.tools.terminal.autoApprove โ Copilot's YOLO. The middle tiers are a terminal allowList / denyList and an OS-level agent sandbox (2026-06 preview). Same trap: once you fully turn off approvals, the denyList is ignored too. And the coding agent's autonomy is a server-side backstop (see the CI entry), not this one local skip switch.
Version notesโ
Trading a permission boundary for fewer interruptions is a general trade-off for all autonomous AI agents, independent of the specific model. The mechanics, though, shift across versions: --dangerously-skip-permissions is a long-standing Claude Code hallmark, while deny/ask/allow rules, auto mode, and the built-in sandbox are newer. Older versions may lack auto mode, so defer to the official permissions docs for the version you're running.