All help topics

Reference · Rules and settings

Permission rule syntax

What a stored Claude permission rule holds and what the add-rule form's fields accept.

The Allow List, on the Claude tab of Settings, holds every rule this app has stored for Claude's own tools. Codex and Gemini carry no rule of this shape; each has its own fixed posture, set before a session starts.

What a stored rule holds

A rule is shown as ToolName(pattern), or a bare ToolName with no parentheses when it carries no pattern. A Bash pattern commonly narrows to a command prefix, such as npm test:* matching any call starting with npm test.

A rule granted from a session's own ask keeps the exact sentence the session showed when it asked. A rule typed by hand on the Permissions screen carries no such sentence. Turret cannot show how many times a rule has fired, or when it last matched — the CLI never reports that.

An allow with no pattern is refused for most tools. It would let the tool run unrestricted, and the bypass mode already covers that. A handful of tools that cannot change anything outside the conversation are exempt, and can be allowed whole.

Adding a rule by hand

A refusal names why the form did not store the rule.

• An allow with no pattern, for a tool that is not exempt.
• A rule matching something already on the Deny List.
• A Read rule whose pattern names a credential path.

Rules read from settings files

Turret also shows the rules already sitting in Claude Code's own settings files, read for display and never written to. Each holds the same allow, deny and ask lists, in the same ToolName(pattern) form, under a permissions key.

Turret reads these in that order and never opens any of them for writing. A change to any of these files is made in an editor or a terminal, not from the Permissions screen.