YOLO Mode - Autohand Docs

Overview

By default, Autohand asks for confirmation before running shell commands, deleting files, and other potentially destructive operations. YOLO Mode lets you bypass these prompts for the tools you name.

# Auto-approve everything (use with caution)
autohand --yolo

# Auto-approve only file reads and writes
autohand --yolo "allow:read_file,write_file"

# Auto-approve everything except deletes and shell commands
autohand --yolo "deny:delete_path,run_command"

Pattern syntax

A YOLO pattern has one mode, allow: or deny:, followed by a comma-separated list of tool names:

Pattern	Effect
`allow:*`	Auto-approve all tools. Same as `--yolo` with no pattern, or `--yolo true`
`allow:read_file,write_file`	Auto-approve only the listed tools
`allow:run_command`	Auto-approve shell commands
`deny:delete_path`	Auto-approve every tool except `delete_path`
`deny:delete_path,run_command`	Auto-approve every tool except the listed ones

Pattern rules

Each pattern uses a single mode, so you cannot combine allow: and deny: in one pattern. Entries are tool names, such as read_file, write_file, run_command, or delete_path. YOLO patterns do not match command text. To block specific shell commands, add denyList entries to your config permissions (see Integration with permissions). To remove a tool from a run entirely, use --disallowed-tools:

# Auto-approve edits, and never allow deletes for this run
autohand --yolo "allow:read_file,write_file" --disallowed-tools "delete_path"

# Only offer read tools for this run
autohand --yolo --allowed-tools "read_file,find_grep,list_tree"

Timeout support

The CLI accepts --timeout <seconds>, described as the time window for auto-approve mode. In the current release, this flag does not end the run or stop commands that are already running. To put a hard limit on an unattended run, use run budgets:

# Stop the run after 10 minutes or 50 model requests
autohand -p "Fix the failing tests" --yolo "allow:read_file,write_file,run_command" \
  --max-duration 600 --max-requests 50

Integration with permissions

YOLO mode works alongside the existing permission system. A YOLO pattern is merged into your permission settings for the session. Deny decisions from the permission system, such as commands in your denyList, still block a call.

Configure standing rules in ~/.autohand/config.json under permissions:

{
  "permissions": {
    "allowList": ["run_command:npm test", "run_command:git status"],
    "denyList": ["run_command:rm -rf *", "run_command:sudo *"]
  }
}

See Configuration for the full permission settings, including rules and mode.

Security considerations

Use specific patterns: Prefer allow:read_file,write_file over allow:*
Block dangerous commands: Add denyList entries for rm -rf, sudo, and curl | sh, and use --disallowed-tools for tools a run never needs
Set run budgets: Use --max-duration, --max-requests, or --max-tokens to stop runaway runs
Combine with config rules: Use config-level denyList patterns as a safety net
CI/CD caution: In automated pipelines, prefer --restricted over --yolo

Tip: Start with narrow allow patterns and broaden them as you build trust. It is easier to add permissions than to recover from an unintended deletion.

Examples

Development workflow

# Auto-approve edits and shell commands; config denyList entries still block rm -rf and sudo
autohand --yolo "allow:read_file,write_file,run_command"

Test-driven development

# Auto-approve edits and test runs, with a time limit for the whole run
autohand --yolo "allow:read_file,write_file,run_command" --max-duration 1200

Read-only analysis

# Auto-approve reads, and offer only read tools
autohand --yolo "allow:read_file,find_grep,list_tree" --allowed-tools "read_file,find_grep,list_tree"