check_read_only() powers the read-only fast path, and check_permissions() performs the tool’s own safety analysis. AgentScope’s built-in tools cover three areas:
The working-directory auto-allow is always subordinate to the safety checks: a dangerous operation inside a working directory still ASKs or DENYs.
Custom Tools
A custom tool implementscheck_permissions() to add tool-specific permission logic. Tools whose read-only status depends on the input (like Bash: ls is read-only, rm is not) should also override check_read_only().
Safety Check Contract
A safety check is a tool-emitted ASK that the tool considers too dangerous to be silently overridden, e.g.Write to ~/.bashrc or Bash with rm -rf /. Setting bypass_immune=True on the decision asks the engine to surface the ASK to the user even when an allow rule matches or the mode would otherwise auto-allow.
Use it whenever a wrong call would cause damage the user almost certainly didn’t intend. Example: a custom DeployTool returns bypass_immune=True when the target is prod-*, so a blanket allow_rules["DeployTool"] = ["*"] configured for staging cannot accidentally authorize a production deploy.
The exact handling per mode:
A regular ASK (
bypass_immune=False, the default) can be overridden by a matching allow rule in DEFAULT/ACCEPT_EDITS, and is silently allowed by BYPASS’s fallback.
Read-Only Commands
Common read-only bash commands are auto-allowed without any rules, in every mode (includingDEFAULT). A compound command (&&, ||, ;, |) is read-only only if all subcommands are read-only. Output redirections (>, >>) always make a command non-read-only. A command flagged with command-injection risk (e.g. ls $(rm -rf /)) is not treated as read-only, so it is not auto-allowed here; it falls through to the tool’s safety check.
Full read-only command list
Full read-only command list