The Agent Permission Model I Want in Every Coding ToolThe Agent Permission Model I Want in Every Coding Tool

Claude Code's permission model has a specific design that most AI coding tools don't: it asks before running shell commands, but it doesn't ask before reading or editing files. That distinction is not arbitrary. Reading and editing is the agent's core job. Executing shell commands has side effects that are harder to reverse. The granularity is correct, and it's the model I want to see everywhere.

---

The Spectrum Is a False Choice

Most discussions of agent autonomy frame it as a dial: on one end, the agent asks before every action; on the other, full autonomy where it just does things. Both extremes are wrong.

Ask-before-everything breaks the workflow. If every file read triggers a permission prompt, the agent is slower than doing it yourself. The friction is the product, not the capability. Full autonomy is wrong for different reasons — the agent makes changes you didn't expect, installs things, rewrites files outside the task scope, and you only find out when something breaks.

The actual answer is granular permissions tied to action type and reversibility. Not a dial — a matrix.

What Claude Code Gets Right

Claude Code distinguishes between four categories of action, and handles each differently:

File reads — allowed freely. The agent needs to read your codebase to do anything useful. Restricting this is like hiring a contractor and locking the rooms.

File edits — allowed freely, but shown in the UI. You see every diff the agent produces. You can reject changes before they compound.

Shell commands (ask by default) — this is where the model earns its thoughtfulness. Before running npm install, git push, rm -rf, or any other command with side effects, it stops and shows you what it wants to run. You approve, reject, or modify.

Network requests — handled via tool permissions. MCP servers expose network capabilities; the agent uses them only if they're configured.

This is the right decomposition. It matches action risk to approval overhead.

The Allow-List Pattern

What makes the system practical is the allow-list. In .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npx tsc --noEmit)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(rm -rf *)"
    ]
  }
}

Pre-approving safe, read-like commands — type checking, linting, test runs, git status — eliminates most of the prompt overhead while keeping guard rails around mutation. The agent can run tests freely. It has to ask before pushing.

This is the pattern I want every tool to adopt. The allow-list is a policy document. It's explicit, reviewable, and version-controllable. Teams can agree on it. New members can read it and understand the trust model.

What the Ideal Looks Like

Beyond what Claude Code does today, the ideal permission model would add:

Task-scoped permissions. When I ask the agent to refactor a specific module, it should only have write access to files in that module for the duration of that task. Scope creep is a real failure mode, and file-level scoping would contain it structurally rather than relying on the model's judgment.

Dry-run mode. Before executing a sequence of shell commands, show me all of them and let me approve the batch. Right now you approve one at a time. Batch approval would work better for longer, predictable task sequences.

Permission profiles. A "read-only audit" profile that locks out all writes. A "full autonomy on this branch" profile for tasks where I trust the output. Switching profiles explicitly rather than tweaking the allow-list each time.

Audit log. Every file write and shell command that ran in the session, timestamped. This exists partially in the tool call display but isn't persisted in a way you can review after the session.

Why This Matters

The fear around AI coding agents isn't irrational — it's that you lose track of what the agent did. A good permission model doesn't just constrain the agent; it creates a record of the agent's actions that you can audit and reason about. That's the difference between a tool that makes you faster and a tool that introduces risk you can't see.

Granular, explicit, auditable permissions are how you get the productivity without the opacity. The permission model is not a safety feature bolted onto an agent. It's what makes the agent usable by a professional who cares about their codebase.