Run Cantrip unattended

Auto-approve every ask permission so CI scripts don't stall — with deny rules still enforced.

When to use it

"Yolo" mode exists for one job: a non-interactive run where stopping on a prompt means a hung build. Typical uses:

• CI charm-build jobs. The runner deploys a charm, waits for active/idle, and exits — nobody is watching for prompts.
• Nightly regression sweeps. You want the agent to iterate on a workload overnight without parking on the first git push prompt.
• Scripted demos. The flow has already been reviewed once; subsequent replays should be frictionless.

If you're working interactively, stay out of yolo mode. The ask tier exists for a reason — you'll notice moments where you want the prompt.

How to enable it

Three ways in, one way out:

$ cantrip run --yolo /path/to/charm   # or ``-y``
$ cantrip run /path/to/charm
> /yolo on
> /yolo off

Bare /yolo toggles; /yolo on and /yolo off are unambiguous forms for scripts. Anything else (/yolo maybe, /yolo yes) is rejected with a usage line.

What changes under yolo

Only the ask tier of the permission policy flips. Concretely:

• Every call whose ruleset lookup resolves to ask auto-approves, with no CONFIRM task and no user prompt.
• Every call that resolves to deny still returns a refused ToolResult with the matched-rule message. Yolo does not escalate denies.
• Every auto-approval publishes a permission_auto_approved event so the transcript captures the rule that would otherwise have prompted — audit trails stay honest.

Plan mode, hooks, and the subprocess sandbox are unaffected. Yolo layers on top of permissions, not around them.

The escape hatch matters

Before you ship a CI script with --yolo, audit .cantrip/permissions.yaml for the commands the run will need. A call that you think is an ask today may become a deny tomorrow when a built-in default tightens — the run will fail loudly rather than silently skipping, which is deliberate. Treat yolo as a convenience for known-good flows, not as a blanket "trust everything" switch.

Two patterns work well:

• Start in interactive mode, run the workload, and convert any ask prompts you actually approve into explicit allow rules in the repo's permissions.yaml. Then the CI run doesn't need yolo at all — the policy itself is the contract.
• When you do need yolo, tighten bash: "rm -rf *" and similar to deny so a drift in the agent's plan can't do real damage. The built-in defaults cover the obvious cases already.

Status indicator

While yolo is on the TUI status bar tints via a -yolo-mode CSS class backed by $error-darken-1 and renders a prominent "YOLO MODE — confirmations off" badge. Every surface that subscribes to STATUS_BAR_CHANGED with a mode field sees the same signal, so the Web and CLI UIs can render their own banner.

Related references

• Configure tool permissions — write allow / ask / deny rules that yolo respects.
• Use plan mode — the complementary "tighten" switch. Plan mode and yolo are mutually exclusive in spirit; enabling both is possible but unusual (plan's narrow allow-list wins).
• cantrip run — full list of flags on the run subcommand.