Blog · Setting it up

The three words that decide what your AI can touch

By George1 October 20262 min read

A pair of tall gates standing half open with warm light behind them.

If you run Claude Code, there is a settings file that decides what it may read, what it must ask you about, and what it may never do. Most people never open it. It is three words, and understanding them takes about five minutes.

The three lists

A permissions object holds three lists: allow, ask and deny. Allow means run it without asking me. Ask means stop and check. Deny means never, and do not ask.

The order is fixed, and it is not the order you would guess

This is the part worth knowing. From Anthropic's own permissions documentation:

Rules are evaluated in order: deny, then ask, then allow. The first match in that order determines the outcome, and rule specificity doesn't change the order.

Read that last clause again, because it is the one that catches people. A more specific allow rule does not beat a broader deny rule. If something is denied, nothing you write later rescues it. That is the right design, and it means the safest way to use these files is to write your deny list first and treat it as final.

Deny and ask start working immediately. Allow does not

There is a second asymmetry in the settings documentation, and it is a good one:

permissions.allow rules... apply only after each teammate trusts the folder... deny and ask rules apply right away.

So a rule that restricts takes effect the moment it exists, and a rule that permits waits for a human to vouch for the folder. If you share a project with someone and your allow rules seem to do nothing on their machine, that is why.

What I actually put in each list

For a small business, the useful starting shape is short.

Deny gets anything with other people's details in it, and anything that would be expensive to undo. A read rule on your secrets file is the standard first entry.

Ask gets everything outward: sending, publishing, paying, deleting.

Allow gets the boring repeated work you have already watched succeed a dozen times, and nothing you have not watched.

That last rule is mine, not the documentation's. Allow is a statement that you have seen something work, and the honest way to earn an entry on that list is to have sat through it going right often enough to be bored.

Where the file lives

The settings documentation lists five places a setting can come from, in precedence order: managed settings from your organization, then the command line, then your project-local file, then the shared project file, then your user file. A key set higher up wins. If a setting is not doing what you expect, something above it is probably setting the same key.

If you want this set up properly against your actual work rather than a generic example, that is exactly what the free consultation is for.

Sources, both fetched 1 October 2026: Configure permissions · Settings files and precedence.

Want this set up against your own work?

Twenty minutes, free, and you leave with a written plan whether or not you hire me.

Schedule a call