Claude Code Permissions for Client Work: Grant Access by Blast Radius, Not Convenience

What Permissions Actually Control in Claude Code

Claude Code runs as a desktop app on your machine, working directly in a project folder. That is its power - it can read the codebase, edit files, and run commands like a developer sitting at your desk. Permissions are the layer that decides which of those actions happen automatically and which stop and ask you first. Out of the box the app is conservative: file edits, shell commands, and network access each surface an approval prompt before anything runs.

You can then shape that behavior per project. Specific commands and tools can be pre-approved so routine work flows without interruption, and everything else keeps prompting. There are also broader modes that reduce prompting across the board - useful on a throwaway prototype, dangerous as a default on client work. The point is that the permission surface is configurable, and on a paid build, configuring it is part of the job. It sits alongside [how you handle client data inside sessions](/blog/is-it-safe-to-use-claude-code-with-client-data) as the unglamorous discipline that keeps you out of apology emails.

The Blast Radius Rule: Sort Every Action by Its Worst Case

The mistake builders make is sorting permissions by annoyance: whatever prompts most often gets approved forever. Sort by blast radius instead - by what the worst plausible outcome of a wrong action would be, and whether you could undo it. That single question splits everything cleanly into three tiers.

• Green - pre-approve: actions that stay inside the project folder and are reversible through version control. Reading files, editing source, running the test suite, local builds, formatting and lint commands. A bad edit here costs you a git checkout, nothing more. Approving these up front is what makes a session feel fast.
• Yellow - prompt every time: actions that leave the project or change shared state but are recoverable with effort. Installing dependencies, running database migrations against a development database, git commits and pushes to a work branch. You want a beat to read what is about to happen before it does.
• Red - never automatic, sometimes never at all: anything that deletes data, touches a live client system, deploys, publishes, or spends money. Destructive shell commands, pushes to a production branch, calls that hit a client's real customer data or a paid API. These stay behind a manual prompt in every session, no matter how many times they come up - and some of them you simply do yourself, outside the agent entirely.

The red tier deserves the most respect on client work because the blast radius is not just technical - it is the relationship. Your own project surviving a bad command is an annoyance; a client's production system taking one is a reference you lose. If a build genuinely requires the agent to touch something red-tier, that is your cue to slow down, not to approve faster.

Setting It Up Per Client Project

Permissions are project-level, which fits client work perfectly: each engagement gets its own folder and its own approval posture. Set it once at kickoff, in the same sitting where you write the project's context files, and the whole engagement inherits it.

1. Start the first session with defaults untouched and do a normal hour of work. Every prompt you see is a data point about what this specific project actually needs.
2. Pre-approve the green tier as it comes up: the test command, the build command, the formatter. Approve the exact commands you trust, not broad categories.
3. Decide your red lines out loud, in writing: which branches the agent never pushes to, which environments it never touches, which credentials never enter the session at all. Keep production secrets out of the project folder entirely - a permission prompt cannot protect a key the agent should never have seen.
4. If you run longer autonomous stretches, tighten first. Reduced-prompting modes and [auto mode sessions](/blog/claude-code-auto-mode-for-client-work) are only as safe as the boundaries you set before walking away - the more autonomy you grant, the shorter the pre-approved list should be.
5. Re-check the setup when the project changes shape. The permission posture that fit the prototype phase is usually too loose once real client data or a live deployment enters the picture.

For rules a prompt cannot express - blocking a specific command pattern outright, or forcing a check before certain actions - [hooks](/blog/claude-code-hooks-for-client-work) pick up where permissions leave off. Permissions decide what asks; hooks decide what is simply not allowed to happen.

Turning a Safety Habit into a Selling Point

Most clients will never ask about your permission setup by name, but nearly all of them are quietly asking the question underneath it: what happens if the AI does something wrong on my project? A one-line answer in your kickoff or proposal - approvals are locked down per project, nothing deploys or touches your live systems without me explicitly confirming it - lands squarely on that fear. You are not teaching them the tooling; you are showing them there is an adult supervising it.

The same discipline compounds through the rest of your delivery. A locked-down permission posture during the build is the daily habit; the [security review before handoff](/blog/claude-code-security-review-for-client-work) is the end-of-build gate; together they become the process language that justifies your rate when a cheaper builder is pitching the same project with none of it. Clients cannot evaluate your code, but they can absolutely evaluate whether you sound like someone who has thought about what could go wrong.