Set command and tool permissions
Rules let a call run without asking, ask you first, or refuse it, so you keep control without approving the same thing every time.
Where the rules live
Open Account → Models → Command permissions. The page lists your rules for shell commands first, and shows a Tool rules block once you have rules for tools as well. Every change saves immediately.
Each rule has one action:
- Allow runs the call without approval.
- Ask requests your approval in web or CLI chat.
- Deny refuses the call.
Add a command rule
- Open Account → Models → Command permissions.
- Type the pattern, such as
git status*, in the rule field. - Choose the action for the new rule: Allow, Ask or Deny.
- Choose Add. The rule joins the list and applies to the next matching call.
Change the action on an existing rule in its dropdown, or remove the rule with the delete button.
Allow a tool instead of asking
Choose Always allow on an approval prompt and Chetty saves a rule for exactly that call: a tool name under Tool rules, or the command under the command rules. Check the list afterwards if you want to know why something stopped asking.
How matching works
Rules are checked in order and the last matching rule wins. Put broad rules first and specific exceptions after them.
git status* Allow
rm * Deny
Write Ask* is a wildcard, so git status* covers git status and longer commands that start the same way. If no rule matches a call, Chetty asks.
A shell line with several commands is checked command by command, for example cd app && rm -rf build. The strictest result applies: one Deny refuses the whole line, and otherwise any Ask asks.
What a rule cannot do
Built-in safety rules still apply underneath your own. A rule cannot grant a tool, a Project or a permission you do not otherwise have.
A Deny rule also holds when nobody is there to approve, so keep one for anything you never want run. Read Approve tool use in unattended runs for what happens to an Ask rule with no person present.