Exec rules

Exec rules are persistent policy decisions stored as TOML files. The runtime evaluates them before the per-tool policy and before any user prompt — denies fail closed.

File location

Each *.rules file under ~/.lime/rules/ is loaded at startup:

~/.lime/rules/
├── shell-allow.rules
├── shell-deny.rules
└── workspace.rules

Format

A rules file is a TOML document with a top-level [[rules]] array.

[[rules]]
pattern   = "cargo test"
action    = "allow"
reason    = "Read-only test runner"
permanent = true

[[rules]]
pattern   = "cargo test --release"
action    = "allow"
reason    = "Release-mode tests"
permanent = true

[[rules]]
pattern   = "rm -rf /"
action    = "deny"
reason    = "Destructive deletion prohibited"
permanent = true

Field	Type	Description
pattern	string	Glob or substring matched against the tool name, the raw input, or the tool_name:input combined string.
action	string	One of allow, deny, ask.
reason	string	Shown in the audit log and /status.
permanent	bool	true for committed long-lived rules; false for session-scoped rules saved by clicking “Allow always” in a permission prompt.

Patterns support * and ? glob wildcards, or you can supply a plain substring. Empty pattern matches nothing.

How rules interact with the policy

Evaluation order on a tool call:

1. Hooks (PreToolUse) — see Hooks. A hook can allow, deny, ask, or rewrite the input.
2. Exec rules — deny short-circuits; allow skips the per-tool prompt; ask forces a prompt even in acceptEdits / dontAsk mode.
3. Per-tool policy — permissions.allow / deny / ask.
4. Permission mode default — default, plan, acceptEdits, bypassPermissions, dontAsk.

This ordering means denies are always enforceable: a deny rule cannot be bypassed by changing the permission mode.

Adding rules

Rules are typically added two ways:

• At a permission prompt. Choosing “Allow always” or “Deny always” writes a permanent = true rule into ~/.lime/rules/<scope>.rules.
• By hand. Edit the TOML directly. Lime watches the directory and picks up changes on next tool dispatch.

There is no /rules slash command in the current build — the slash surface for rules has not shipped. Manage rules via files for now, or through the permission UI.

Inspecting

/status         Shows the count of loaded rules and recent decisions.
/config         Inspect merged config sections including permissions.

Example: lock down bash for a CI worker

~/.lime/rules/ci-bash.rules

[[rules]]
pattern = "bash:*"
action  = "deny"
reason  = "CI worker — no shell access."
permanent = true

[[rules]]
pattern = "bash:cargo test*"
action  = "allow"
reason  = "Test runner explicitly allowed."
permanent = true

The deny on bash:* blocks every shell call by default; the second rule allows the test runner specifically. Order matters — the more-specific allow runs before the broad deny because rules are evaluated in declaration order.