Rules
Add event-based guidance, blocking, follow-up, and checks to Claw workflows
Rules let you shape Claw behavior around recurring moments in a workflow. A rule combines an event, optional match conditions, and an action.
Open Settings > Rules to create and manage rules.
What Rules are for
Use Rules when you repeatedly need Claw to:
- Follow standing guidance before replying
- Stop matching risky commands before they run
- Add context after a tool result
- Follow up after edits or other actions
- Run a narrow check after matching work
Rules are operational controls. They complement Working Styles, permissions, approvals, and Security settings.
Rule model
Each rule has:
- Name
- Description
- Enabled/disabled state
- Event
- Optional matcher
- Action
- Source/scope
Start with one small rule and validate it in a low-risk chat before broad use.
Supported events
Current wired events are:
- When a chat starts
- Before Claw replies
- Before an action runs
- After an action finishes
Other event names may appear in the internal model for future expansion, but the currently wired events above are the ones to rely on for day-to-day rules.
Match conditions
Rules can match on:
- Prompt or input text
- Action/tool category
- Specific action/tool names
- Command text
- Tool result text after an action finishes
Tool categories include common groups such as commands, file changes, file reads/searches, web actions, helper agents, task list updates, or specific custom action names.
Actions
Available actions depend on the event.
- Add guidance: adds standing guidance before Claw replies
- Stop an action: blocks a matching action before it runs
- Add a note after an action: appends context to a tool result
- Ask Claw to follow up: queues a follow-up instruction after matching work
- Run a command: runs a configured command before or after matching tool use
Use Run a command carefully. Keep commands narrow, deterministic, and scoped to the expected workspace.
Built-in starting patterns
Useful first rules include:
- Add a release checklist reminder when a prompt mentions release work
- Block
git pushuntil the operator explicitly decides to push - Request a follow-up review after file edits
- Run a small test or validator after matching file changes
Avoid broad catch-all rules at rollout. They are harder to debug and can make Claw behavior feel inconsistent.
Rules and security
Rules are not a substitute for hard security controls.
Use them with:
- Security for sender, folder, network, and approval policy
- Agents for runtime and permission scope
- Airlock for website access policy
- Working Styles for response posture
If a rule blocks an action, Claw receives a tool error explaining which rule stopped it. If a rule adds follow-up or command output, Claw sees that as part of the turn context.
Rollout guidance
- Create one rule for one recurring pattern
- Test it in a non-critical chat
- Confirm it fires only when intended
- Document why it exists
- Add more rules only after the first one is predictable
Keep rule names specific. A future operator should be able to understand the intended behavior from the name and description.