Auto-approval & guardrails
Let agents keep moving with a rules engine, while a hard deny-list, audit trail and kill-switch keep you safe — at any autonomy level.
OFM can auto-answer repetitive confirmations so agents don’t stall — without giving up safety. You choose how much autonomy to grant; the guardrails hold regardless.
Autonomy levels
Set the level globally, or override it per project:
human— always ask. Nothing is auto-injected (beyond the hard deny-list below).allowlist— the safe default. Only confirmations matching an explicit rule are auto-approved.broad— auto-approve simple approvals by default (still subject to the deny-list).
The rules engine
A rule maps a confirmation pattern to allow or deny. Rules are evaluated by a strict
pipeline (first match wins): kill-switch → hard deny-list → human level → user deny → allow
rule → broad default → otherwise ask a human.
Rules can be scoped (global or per project), limited to a provider, and matched by exact action, action prefix, command regex, path glob, or choice kind.
Learning from the queue
Resolve a confirmation in the queue with “remember” and OFM creates a rule from it (conservative by default: project-scoped, provider-scoped, action-prefix). Resolve the same credit or permission prompt once and every later session in that project passes it without asking again.
Hard deny-list
A non-removable, compiled deny-list always wins — destructive commands (rm -rf, git push,
git reset --hard, fork bombs, disk writes, piping the network into a shell, …). Depending on
your setting, a hard-denied action is either auto-refused or surfaced to you with a red banner;
it is never auto-approved.
Kill-switch
One switch above every rule: the kill-switch stops all auto-injection of confirmations. Agents keep running; you answer everything by hand.
Honesty
The audit log explains every decision and lets you correct or disable a rule — but it does not undo effects an agent already produced on disk. Guardrails are about preventing and explaining, not time travel.