Permissions

What I write about here ​

Permissions are where the gap between what you configured and what is actually enforced shows up fastest.

The recurring finding across these posts is that the two halves behave differently. A rule that takes capability away tends to bind immediately and everywhere. A rule that hands capability over waits for something: a dialog someone has to accept, a workspace someone has to trust, a mode that is not active in the session you happen to be in. Write both into the same file and only one of them is doing what you think.

The second recurring finding is that a permission boundary is usually thinner than its name suggests. A denied path can still surface in the output of a shell command that lists it. An approval given inside a throwaway workspace can outlive the workspace. A file that keeps local overrides out of git turns out to be excluded by a global ignore rule that the repository never records, so a hand-created one has no protection at all.

None of this is an argument against configuring permissions. It is an argument for knowing which of your rules are load-bearing. The ones that restrict, plus a hook, are the two things that hold on their own.

The wider picture of what you hand over when you give an agent tools is in the MCP and security guide.