OpenClaw is where DashClaw's “Claw” comes from: it was the first agent runtime we governed, and this plugin remains one of the deepest integrations: the full guard → record → approval → outcome loop on every tool call, with token-cost attribution built in.
Integration Guide
OpenClaw
One command wires DashClaw governance into an OpenClaw agent. Restart the gateway and your next tool call shows up in /decisions.
Instance URL detected: https://your-dashclaw-instance.example.com
Prerequisites
Three things before you start: OpenClaw installed and on PATH, a running DashClaw instance (deploy one or use an existing one), and an API key for that instance (it starts with oc_live_).
Already have all three? Skip to Step 2.
Run the install command
One command installs the dashclaw-governance plugin, patches your OpenClaw config, enables the plugin, and writes the governance block into AGENTS.md. Give every machine its own --agent-id: moltfire-openclaw, forge-openclaw, whatever fits your fleet. Reuse one id across machines and /decisions cannot tell the agents apart. Add --base-url if this machine has no DASHCLAW_BASE_URL and no saved config.
Terminal
dashclaw install openclaw --agent-id moltfire-openclaw
The API key is written as DASHCLAW_API_KEY to the .env beside your openclaw.json, so it follows openclaw --profile rather than always landing in the default profile. Pass --write-config to store it in openclaw.json instead. The key is written before the plugin is enabled, on purpose: a plugin that comes up with no key refuses every tool call. The installer also sets failClosed: true, and there is currently no flag to change it: if DashClaw is unreachable, the plugin blocks the call instead of letting it through.
Restart the gateway
OpenClaw reads plugin config when its processes start, so the newly enabled plugin has no effect until you restart.
Terminal
openclaw gateway restart
Trigger a governed tool call
Start the agent and give it something that uses a governed tool: bash, write, edit. From here governance is automatic. Guard runs before the call, a record opens, the call waits if a policy requires approval, and the outcome is recorded after. The agent calls no DashClaw tools itself. An Agent Session opens on its first tool call and closes when the run ends.
Example prompt
Create a file called hello.txt with the contents "Hello from a governed agent"
Watch the gateway logs. You should see [dashclaw-governance] entries as the plugin classifies and guards the call.
Verify it is working
Two checks: ask OpenClaw if the plugin is healthy, then look for the tool call in DashClaw.
Terminal
openclaw plugins doctor
Then open /decisions in your DashClaw instance. The tool call should be there within seconds, tagged with the agent id you installed with.
What success looks like
Go to /decisions. You should see your OpenClaw tool call in the ledger with agent_id 'moltfire-openclaw', a classified action_type that matches the tool call, and status 'completed'. Token usage and cost are attributed automatically once the agent's next LLM turn completes.
Navigate to /decisions in your DashClaw instance. Your action should appear in the ledger within seconds of the agent run.
Governance as Code
guardrails.yml is a policy-as-code template. Import it into your instance — POST the YAML to /api/policies/importor call the Python SDK's import_policies — and DashClaw evaluates these rules at the guard step before any action executes.
guardrails.yml
version: 1
project: my-openclaw-agent
description: >
Governance policy for an OpenClaw agent.
Block destructive shell commands.
Require approval on deployment commands.
policies:
- id: block_destructive_shell
description: Block irreversible filesystem destruction
applies_to:
tools:
- bash
- exec
rule:
block: true
when:
command_contains:
- "rm -rf"
- "drop table"
- id: approve_deploys
description: Production deploys require human approval
applies_to:
tools:
- bash
rule:
require: approval
when:
command_contains:
- "git push origin main"
- "vercel deploy"
- "kubectl apply"What gets governed
The plugin classifies each tool call before it executes. Bash commands are parsed against known intent sets (git, rm, curl, npm). File operations are scanned for sensitive paths (.env, credentials, private keys). Unknown tools fall through to action_type other with a configurable default risk score of 50. Tools listed in highRiskTools, set in the same openclaw.json the installer patches, start at risk 85 instead of the default. A pattern match then takes precedence over that starting score in both directions: a destructive command scores 90, a deploy scores 80, and read-only tools are capped at 15 no matter what they started at.
| Tool call | action_type | Risk | Reversible |
|---|---|---|---|
| write: hello.txt | apply | 50 | yes |
| bash: git push origin main | deploy | 80 | no |
| bash: rm -rf /tmp/data | security | 90 | no |
| write: .env.production | security | 85 | yes |
| read: config.json | review | 15 | yes |
The classification vocabulary matches the DashClaw Claude Code hooks, so guard policies you write for one apply automatically to the other. Full reference and configuration options: @dashclaw/openclaw-plugin README.
Automatic identity pairing
Click Request pairing next to your agent on /identitiesand the plugin answers on the agent's next tool call: it generates an RSA-2048 keypair locally, submits the public key, and the pairing appears under Pending Pairings for your one-click approval. The private key is written to ~/.dashclaw/identity/<agentId>.pem and never leaves the agent's machine. Approval is what creates the identity — the agent cannot enroll itself. Disable with autoPairing: false in openclaw.json, the same file the installer patches.
Troubleshooting
“My agent says it cannot reach the dashclaw MCP server.” OpenClaw has no DashClaw MCP server, and never did. Governance runs at the gateway: the dashclaw-governance plugin intercepts every tool call before it executes, so the agent is not supposed to call anything itself.
If AGENTS.md instructs the agent to call dashclaw_session_start through an MCP server, that block came from dashclaw install codex running against this same workspace, which is easy to do if the OpenClaw agent runs Codex as its underlying runtime. The agent then fail-closes on a tool that does not exist here, even though the gateway plugin is governing every call correctly the whole time.
Fix: re-run the install command. It recognizes the codex-authored block, replaces it with the OpenClaw protocol, and leaves a .dashclaw-bak copy of what was there before.
dashclaw install openclaw --agent-id moltfire-openclaw