When Claude Code wants to run a command, it pauses and asks for your approval first:
I'll run: ls -la /var/log/
Allow? (y/n)That friction is intentional. And for security practitioners, it matters more than you might think.
Why the Pause Exists
Claude Code can execute arbitrary commands on your system. Read files, write files, run programs, make network requests—anything you could do from a terminal.
Before taking any action that could modify your system, access sensitive data, or have side effects, it pauses to give you a chance to verify.
For security work, this matters even more than typical development. You might be connected to production systems. You might be analyzing live malware samples. You might be handling sensitive investigation data.
The pause between "Claude wants to do this" and "I'm letting it" gives you a critical moment to think: is this actually what I want to happen?
Think of it as being a good manager who peeks over the shoulder of an extremely zealous, highly capable, but occasionally fallible analyst. You want them to move fast—but not so fast that you can't catch the one time they're about to do something regrettable.
The Safety Tradeoff
Permission friction exists on a spectrum.
On one end: maximum friction—Claude asks before every single action, no matter how benign.
On the other end: maximum trust—Claude does whatever it thinks is needed without ever asking.
Neither extreme is right.
Maximum friction makes work painfully slow—constantly typing 'y' to approve obviously safe operations. Maximum trust is dangerous—Claude might misunderstand your intent or do something you didn't expect.
The goal is finding your balance point.
When to Accept More Friction
More friction makes sense when:
- You're still learning Claude Code and want to see what it tries to do
- You're working with sensitive systems where mistakes would be costly
- Commands could have irreversible effects
- You're not quite sure what Claude might attempt
When to Reduce Friction
Less friction makes sense when:
- You're running read-only commands repeatedly
- You trust Claude's judgment for common operations
- Speed matters more than extra verification
- The commands are easily reversible if something goes wrong
Pre-Approving Safe Commands
You can pre-approve specific commands so Claude doesn't need to ask about them. These go in the permissions section of your settings:
{
"permissions": {
"allow": [
"Bash(ls:*)",
"Bash(cat:*)",
"Bash(grep:*)",
"Bash(find:*)",
"Bash(head:*)",
"Bash(tail:*)"
]
}
}With these rules in place, Claude can run ls, cat, grep, and the other listed commands without asking for permission.
The pattern syntax lets you be specific. Bash(ls:*) means allow ls with any arguments. Bash(git:status) means allow only git status exactly—not git push or any other git command.
Recommended Permissions for Security Work
For security analysis, a good starting set is read-only commands that help investigation without modifying anything:
{
"permissions": {
"allow": [
"Bash(ls:*)",
"Bash(cat:*)",
"Bash(head:*)",
"Bash(tail:*)",
"Bash(grep:*)",
"Bash(find:*)",
"Bash(file:*)",
"Bash(strings:*)",
"Bash(xxd:*)",
"Bash(jq:*)",
"Bash(git:status)",
"Bash(git:log*)",
"Bash(git:diff*)"
]
}
}All of these are read-only or informational. They examine data without changing it. Even if Claude misunderstands your intent and runs one unexpectedly, the damage potential is minimal.
Notice what's deliberately absent: rm, mv, chmod, curl, git push, git commit. Anything that modifies state stays behind the permission prompt.
Using Deny Rules
Sometimes you want to explicitly forbid certain commands, even if they'd otherwise be allowed:
{
"permissions": {
"allow": ["Bash(git:*)"],
"deny": ["Bash(git:push*)", "Bash(git:reset*)"]
}
}This allows all git commands except push and reset. Deny rules override allow rules.
Useful when you want broad permissions with specific exceptions.
The Principle
Pre-approve operations that can't cause harm. Keep approval on operations that could.
If you find yourself tempted to skip all permissions because the prompts are annoying, that's a sign you need to add more allow rules for safe commands—not that you should remove all guardrails.
The friction isn't slowing you down. It's protecting you from the one time Claude misunderstands and tries to do something irreversible.
Key Takeaways
Permission friction is intentional protection, not annoyance — The pause exists to give you a chance to verify before potentially harmful actions.
Find your balance point based on risk tolerance and current work — More friction for sensitive systems, less for routine exploration.
Pre-approve read-only commands you use constantly — Commands like ls, cat, and grep are safe to auto-approve.
Keep approval on anything that modifies state — Writes, deletes, network operations, and commits should require explicit approval.
Deny rules let you carve exceptions from broad permissions — Allow a category while blocking specific dangerous commands.