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 guard → record → approval → claim → outcome loop on every tool call, with token-cost attribution built in.
Integration Guide
OpenClaw
One command wires DashClaw governance into an OpenClaw agent — even with no DashClaw instance or API key yet; it offers to create both. Restart the gateway and your next tool call shows up in /decisions.
Instance URL detected: https://your-dashclaw-instance.example.com
Prerequisites
One thing before you start: OpenClaw installed and on PATH. A DashClaw instance and an API key help but are no longer required — run the install command without them and it offers to create both: the free hosted trial (sign in, paste the minted key) or a local instance on this machine via dashclaw up.
The CLI comes with npm: npm i -g @dashclaw/cli, or run everything through npx @dashclaw/cli.
Run the install command
One command asks for anything it is missing, then installs the dashclaw-governance plugin, patches your OpenClaw config, enables the plugin, and writes the governance block into AGENTS.md. It prompts for an agent id with a per-machine default (<hostname>-openclaw): moltfire-openclaw, forge-openclaw, whatever fits your fleet. Reuse one id across machines and /decisions cannot tell the agents apart. Flags (--base-url, --api-key, --agent-id) or env vars skip the prompts; without a terminal the command fails loudly instead of hanging.
Terminal
dashclaw install 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. Already ran "openclaw plugins install @dashclaw/openclaw-plugin" by hand? Run this command anyway: the raw install only puts the plugin on disk, with no key, no config, and not enabled. The installer detects it, keeps it (it never downgrades an equal-or-newer version), and finishes the rest.
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. Current policy runs before the call, one action record opens, the call waits if approval is required, and protocol 1 claims the exact action and principal before the host tool runs. Approval is consumed at the claim, 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/import or 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.
During a server-first upgrade, a response with neither claim advertisement field keeps the legacy guard and approval flow. A partial or invalid advertisement blocks the call. Set DASHCLAW_REQUIRE_EXECUTION_CLAIMS=1 after the server supports protocol 1 to reject legacy responses that omit claim negotiation. A lost or rejected claim acknowledgement never releases the host tool and is not retried automatically.
Automatic identity pairing
Click Request pairing next to your agent on /identities and 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