Control what runs without asking

Your own rules decide which shell commands and tools Chetty may run silently, which it must ask about, and which it may never run at all.

Before you start

These rules belong to your account and apply to your conversations. Every change here saves immediately, and an administrator can edit the same settings for your account in Users.

Approval prompts only appear in interactive chat, in the web app or the CLI. A scheduled job, a channel conversation or a sub-agent has nobody to ask, which is why Unattended runs exists.

YOLO mode

Automatically approve requests to use tools (YOLO) skips the approval prompts in new sessions, so work keeps going while you look away.

1. Open Account → Models.
2. Switch on Automatically approve requests to use tools (YOLO).
3. Confirm with Enable YOLO in the dialog that explains the risk.

Warning: YOLO is not a permission bypass. A rule that denies a command or tool still blocks it, and Block in Unattended runs still stops an approval in work nobody is watching. Turn it off when the task is done.

Unattended runs

Unattended runs answers one question: what happens to a rule that says Ask, when the work runs without you — a scheduled job, a platform conversation or a sub-agent.

Explicit Allow and Deny rules behave the same either way, and YOLO does not override Block.

Command permissions

Command permissions lists your rules for shell commands. Each rule is a pattern and an action; * matches anything.

1. Open Account → Models and find Command permissions.
2. Choose Manage to open the full editor. The card previews the first rules.
3. Enter a pattern such as git status* in the add row and pick its action, then choose Add.
4. Repeat for every command you want covered, then close the editor.

Order matters: the last matching rule wins. A new rule goes to the end, and adding a pattern that already exists moves it there. Remove a rule with Remove rule.

Chetty's own defaults are not listed in the editor. They allow every shell command, so a command your rules do not mention runs without asking; and they ask before Write, Edit and TransferFile, while allowing every other tool.

Your rules are checked after those defaults, so yours win wherever they apply. A denial you want therefore has to be spelled out — only your rules, Block in unattended work and Plan mode hold a command back.

git status*   Allow
rm *          Deny

Commands you approve with Always allow in chat are added here automatically, so the list also shows what you have already trusted.

Tool rules

The same card keeps Tool rules for tool names, with the same Allow, Ask and Deny actions and the same last-match-wins order. They appear below the command rules once some exist, and they apply to every tool the model may call, including tools a plugin contributes.

A rule naming a tool Chetty does not have is harmless: it simply never matches.

The built-in defaults already ask before Write, Edit and TransferFile, so a tool rule is only needed to change that for your account.

If a command was blocked

• Check the last matching rule. A broad Deny such as rm * added after a narrower Allow wins, because the last match decides.
• Look for Block in Unattended runs when the failure appears in scheduled or channel work.
• Read the approval request in the conversation: it names the command and the rule that stopped it.
• Ask an administrator when a rule you did not add appears in the list; the same settings can be edited for your account in Users.

Related guides

• Autonomy & Safety
• Approvals in unattended runs
• Account settings overview
• Set command and tool permissions
• Approve tool use in unattended runs