DocsConfigure
Permissions & safety
How Rusty asks before running commands, and the tool limits and rules that keep agents in bounds.
Agents act on your real files and can run commands with your credentials, so Rusty puts several layers between an agent and a risky action. Each layer is independent, so you can combine them.
Command permission prompts
When an agent wants to run a shell command, Rusty stops and shows Command permission required. The prompt tells you:
- The command, with its arguments.
- A risk badge:
elevatedordestructive. Destructive commands carry an extra warning, because they may modify infrastructure, remote systems or project state. - The working directory the command will run in.
- The timeout, in seconds.
The command runs against your real workspace files, in the IDE's own environment, and may use any local or cloud credentials you have configured. Read it before you approve.
You have three choices:
| Button | Effect |
|---|---|
| Deny | The command is refused, and the agent is told so. |
| Allow once | Runs this one command. |
| Allow program this session | Allows other normal-risk commands from the same program for the rest of this agent session. When a command cannot be safely grouped by program, the button reads Allow exact command this session and applies only to that exact command. |
Session grants are held in memory only. They end with the agent session and are never saved. Elevated or destructive variants of an allowed program still ask again, and changing an exact command's arguments asks again.
Tool allow-lists
A profile can restrict a workflow step to a named set of tools. The built-in Plan step is limited to reading and searching tools, so it cannot edit files or run commands at all:
"tools": {
"type": "allow_list",
"tools": ["read_file", "list_files", "search_codebase", "web_search", "web_extract", "report_progress", "ask_user_question"]
}
Read-only workflows and Auto
The built-in workflows use these tool limits on purpose. Research, Analyze, Plan, Architect, Security and Review cannot write files or run commands, and Debug and Verify cannot write files, so a stage such as Research & analyze or Verify & review changes cannot change your project. Only Build, Refactor, Optimize and Document steps can. See Built-in workflows.
When Auto flows choose a workflow for you, they never start one that can change files without asking first, and they ask again before handing a running workflow over to one. Command permission prompts apply inside every workflow.
Rules
Profile rules run on events and can deny, ask or allow a specific tool call, rewrite its arguments, or stop the run. Use them for guardrails that always apply, for example refusing writes in a read-only step:
{
"id": "plan-read-only",
"on": "PreToolUse",
"when": { "tool": ["write_file", "run_command"] },
"do": { "deny": { "reason": "The plan step is read-only. Describe the change in the plan instead of making it." } }
}
The reason you give is what the agent reads, so make it say what to do instead.
Completion gates
A completion gate prevents a step from finishing until required checks are met. The built-in Build step cannot report until it has verified its own edits.
Risk review (experimental)
Before an agent destructively overwrites a file or runs a destructive command, the decision model can review the step. It can let the step run, send the agent back to revise, or ask you. The settings panel keeps counts of what it allowed, blocked and sent back. This needs OpenRouter connected with a decision model chosen. See Automatic model selection.
Review before you commit
Whatever the agent did, Git is your last checkpoint. Look at the diff in Source control before you commit. In Rusty Canvas, task results are written to an isolated virtual workspace first, and you decide when to apply them to the real one.