Steps

•
Determine the rule from the conversation context. Prefer broad patterns over narrow ones:
- •Good: allow bash git * (covers all git commands)
- •Avoid: allow bash git status (too narrow, user will hit another prompt soon)
- •If unsure, ask the user what they want to allow.
- •
  If the request involves a directory path or filesystem access (e.g., "allow access to ~/Library/Caches"):
  - •Use allow * * as the rule with a --fs constraint
  - •Example: $CLASH_BIN policy add-rule "allow * *" --fs "full:subpath(~/Library/Caches)"
  - •Capabilities: read, write, create, delete, execute, or full (all of the above)
  - •Filters: subpath(path), literal(path), regex(pattern) — combinable with | (or) and & (and)
•
Confirm with the user before making any changes:
- •Show the exact rule that will be added
- •Show which profile it will be added to (the active profile by default)
- •Explain what the rule means in plain English

•

Dry-run first to preview the change:

bash

$CLASH_BIN policy add-rule "RULE" --dry-run
# Or with filesystem constraints:
$CLASH_BIN policy add-rule "allow * *" --fs "full:subpath(~/dir)" --dry-run

Show the output to the user.

•
Get confirmation, then apply:
bash
```
$CLASH_BIN policy add-rule "RULE"
```
•
Report success and explain that the rule is now active.

Safety guidelines

•Always dry-run first and show the result before applying
•Never suggest rules that override intentional deny rules without explicit user consent
•Never suggest allow * * or allow bash * without explaining the security implications and getting explicit user consent
•If the user asks to allow something that is currently denied, warn them that deny rules always take precedence (even over constrained allows) and they may need to remove the deny rule first
•If the user wants an allow rule to override a broader ask, suggest adding inline constraints (url, args, etc.) to the allow rule — constrained allows beat unconstrained asks
•Prefer scoped rules (e.g., allow bash git *) over broad wildcards