Settings, permissions and hooks
An agent that can write files and run programs needs boundaries. In Claude Code, those boundaries are not vague promises : they are configuration, written in a file ( .claude/settings.json ) that you control. Two mechanisms matter : permissions and hooks.
Permissions : the three zones
Every action the agent might take falls into one of three zones, and you draw the lines :
| Zone | What happens | Examples you might choose |
|---|---|---|
| Forbidden ( deny ) | The action is refused, full stop | Reading password files, deleting folders, force-operations |
| Ask first | The agent pauses and asks you | Sending an email, publishing a page, paying anything |
| Allowed | The agent proceeds on its own | Reading project files, running tests, saving its work |
This is the practical meaning of « humans set the rules, the agent executes ». Autonomy is not on or off : it is a dial per type of action. A new setup starts conservative ( almost everything asks ) ; as trust builds, you move routine actions to « allowed » and keep the sensitive ones gated.
A real example from our own configuration at eaQbe : the agent may read any project file and run any test alone ; it must ask before sending any email ( and show a preview ) ; it may never read credential files or force-delete anything : those are denied even if asked nicely.
Hooks : automatic reflexes
Permissions decide whether an action runs. Hooks are small automatic checks that run around the agent's actions : without the agent ( or you ) having to think about them.
A hook is a rule of the form : « when X happens, run Y ». Concrete examples from production setups :
- At session start : check that the critical systems are running and tell the agent their status : so it starts informed.
- Before any risky command : a guard inspects what is about to run and blocks dangerous patterns : even if the agent was tricked into trying.
- After every file edit : an automatic check validates the file ( does it still parse? ) so a typo is caught the second it happens.
- Before delivering an answer on sensitive topics : a reminder fires : « verify this against the live system, not from memory ».
The analogy : hooks are the safety interlocks of a machine. The operator does not have to remember the safety procedure : the machine physically enforces it. Hooks turn your best practices from « things we hope the agent remembers » into « things that happen every single time, mechanically ».
Why this matters beyond safety
Permissions and hooks are usually presented as safety features : and they are. But their deeper value is trust calibration. Because the boundaries are explicit and mechanical, you can delegate more aggressively inside them. Teams without guardrails either over-supervise ( and gain nothing ) or under-supervise ( and get burned ). The configuration file is what lets you do neither.
Frequently asked questions
Can Claude Code do things without my permission?
Only what you placed in the « allowed » zone. Everything else either asks you first or is refused. The zones live in a settings file you can read and edit at any time.
What is a hook in Claude Code, in simple terms?
An automatic « when X, do Y » rule that runs around the agent's actions : a check at session start, a guard before risky commands, a validation after each edit. Reflexes, not advice.
What should be in the « ask first » zone?
Anything irreversible or outward-facing : sending messages, publishing content, spending money, deleting data. The rule of thumb : if you would want a junior employee to check with you first, put it in « ask ».
Going further
- Next : Skills & sub-agents : giving the agent specialized know-how.
- We configure these guardrails live, on your use case, in the Claude Code training.