Navigation
ELOWEN · Documentation

Last updated: October 27, 2026

Browse documentation · Set permission rules and YOLO defaults
Accounts, access and security

Set permission rules and YOLO defaults

Permission rules decide whether a tool call runs, waits for a person or is refused, and every account can hold its own set or inherit the instance defaults.

Where rules live

Each account edits its own rules in Account → Models → Command permissions, where changes save immediately. Command permissions holds patterns for shell commands, and Tool rules holds patterns for tool names.

An administrator sets the rules that accounts without their own value inherit under Users → Options → Default settings for users → Rules and YOLO.

The three actions

Action What happens
allow Runs the call without approval.
ask Requests approval wherever a person can answer.
deny Refuses the call.

A rule can never grant a tool, a project or a permission the account does not otherwise have.

How a call is checked

Rules run in order and the last matching rule wins. Built-in defaults come first, so an account's own rule always beats a default, and within one account a later rule beats an earlier one. Adding a pattern that already exists moves it to the end.

tools patterns match a tool name, such as Write. Shell commands are matched in the bash pattern space against the command string, so git * and rm * can differ even though both use the Bash tool.

Built-in defaults

With no rules of its own, an account allows tools, asks for Write, Edit and TransferFile, and allows shell commands. Nothing is denied by default.

Plan mode, read-only delegation and unattended runs each apply their own restrictions on top; they are not rules you can edit.

Lines with several commands

A line such as cd app && rm -rf build is split at ;, newlines, &&, ||, | and &. The inner command of every substitution, such as $(…), backticks, <(…) or >(…), is checked as well.

Each part is resolved on its own and the most restrictive result applies: any deny blocks the whole line, otherwise any ask asks.

An allow rule matches the command as written, so a path-qualified or env-prefixed spelling does not inherit it. A deny rule also matches that plain spelling, so rm * still catches /bin/rm and FOO=1 rm. An unbalanced quote or an unterminated substitution makes the line ask at most, while a deny still applies.

YOLO mode

YOLO removes prompts by turning every ask into allow. It never overrides an explicit deny, and it never makes an unavailable tool available.

It is off by default. The toggle in Account → Models sets the default for new sessions, while /yolo in elowen chat changes only the current session.

Unattended runs

Scheduled runs, delegated sub-agents and chat platforms have nobody waiting to approve a call. Account → Models → Unattended runs decides what an ask means there:

  • Allow, the default, treats the ask as allowed.
  • Block refuses ask calls in unattended turns.

This setting is independent of YOLO, and YOLO does not override Block. Read-only delegated sub-agents always refuse an ask, whatever this setting says.

Set the rules everyone inherits

  1. Open Users → Options → Default settings for users.
  2. Open Rules and YOLO.
  3. Set the rules, the YOLO default and the unattended answer.
  4. Use Apply to everyone on a field to clear an account's own value, then confirm.

The three are one record: an account either holds its own rules, YOLO and unattended answer together, or inherits all three.