Approvals & Safety

The assistant can edit your files, run console commands on your live server, and write to your database. It does not do any of that quietly.

The rule

Risk decides everything:

• Reads run silently. Opening a file, searching your project, checking server status — 41 of the 61 tools never interrupt you.
• Writes and executes stop and ask. An approval card appears in the chat with a one-line summary of what is about to happen, and the turn waits.

Nothing runs while a card is waiting. Denying is a normal answer, not an error — the assistant is told it was denied and carries on from there.

What a card offers

Button	Effect
Allow	This one call runs
Allow all for <path>	Every queued and future call in this turn touching that path runs
Deny	This call does not run

The scoped grant exists because a single rename can touch one file eight times, and clicking eight identical cards is not consent, it is fatigue. Answering once clears every queued card the grant covers.

Reading the trail afterwards

Every risky call leaves a record of how it was settled, visible on the tool card after the fact:

Label	Meaning
Allowed by you	You clicked Allow
Denied by you	You clicked Deny
Ran under an earlier “allow all”	Covered by a scoped grant you gave
Auto-allowed by policy	Its risk level does not require asking
Auto-denied by policy	Blocked outright
No answer — timed out	The request expired unanswered

Nothing that changed your project is missing from this list. A call that ran silently still says so.

The floor nothing can cross

Some commands are refused before the policy engine is consulted at all, and no setting, grant or instruction can re-enable them. This is a deliberate hard floor, not a default:

• rm -rf / and its variants — including flag reordering, -- separators, path traversal like /tmp/../.., multi-path expansions, and $HOME or ~ forms
• dd writing to a block device
• mkfs against a volume

Shell substitution is also refused inside any command that needs approval — $VAR, ${VAR}, $(...), backticks, $((...)), <(...) and >(...). The reason is that a card can only be honest if the command on it is the command that runs; a substitution means the text you approved and the text the shell executes are not the same thing.

Caution

This floor covers catastrophic, unrecoverable operations. It is not a substitute for reading what you are approving. A command that deletes your resources/ folder is not on this list, because it is a normal file operation — it will show you a card, and it will do exactly what the card says.

What is not gated

memory_save is the one write that runs without a card. Saving something the assistant should remember is not a risky operation, and interrupting for it would train you to click Allow without reading. It is still recorded in the audit trail as auto-allowed, because silent is acceptable and invisible is not.

Tools you do not have

Tools are only offered when they can actually work. With no server running, the live-server tools are not registered at all; the same goes for the database tools with no connection. The assistant is told in prose what is unavailable and why, so it explains the gap rather than trying the call and failing.