DashClaw: a fail-closed approval layer for unattended AI agents

The gap DashClaw targets: an agent that acts while nobody is watching

Most agent stacks give a tool call the same authority whether a human is present or not. The README frames the project around that asymmetry: run agents unattended without giving them unconditional authority. The intended user is someone running Claude Code, Codex, Hermes or OpenClaw in a loop, overnight or in CI, where an `rm -rf` on a working directory or a `git push --force origin main` is not recoverable by re-prompting.

The project's own list of catches in the maintainer log and THESIS.md is concrete rather than hypothetical: `rm -rf` on a working directory, `DROP TABLE` against a live database, `git push --force origin main`, and a read of `.env` preparing to exfiltrate it, which the log records at risk 100 with two policies firing at once. That last item is the interesting one. Deleting a file is a blast-radius problem; reading a credential file is a data-egress problem, and both are supposed to route through the same approval path.

This is governance tooling, not a sandbox. It does not isolate the agent's filesystem or network. It inserts a decision point and a record.

How the intercept works, and where it stops being an intercept

DashClaw sits between the decision and the execution. The README describes a fail-closed intercept at the execution seam: the Claude Code, Codex and Hermes hooks, the OpenClaw gateway, and `dashclaw_invoke` can cancel a blocked call before it runs. In those paths the verdict is enforced by the integration itself, and a blocked call does not execute.

Everything else is cooperative. Bare SDK, API and ordinary MCP integrations still evaluate and record governance, but the caller has to honor the result. That distinction is the single most important thing to understand before adopting this, and it is stated plainly in the README rather than buried. If your agent calls the REST API directly, DashClaw will tell you an action should be blocked; whether it is blocked depends on code you wrote.

The decision flow is: agent proposes a tool call, the guard evaluates it against policy, the call is either allowed, blocked, or held for approval. Held items land in the `/approvals` inbox and can be resolved from the CLI, a phone PWA, Telegram or Discord, so no keyboard presence is required. Resolving writes a decision record, and the README states that decision records, Ed25519 receipts where issued, and signed exports support later review. It also draws a boundary worth repeating: a receipt verifies its signed contents, not that an external effect happened.

Two mechanisms sit on top of the basic loop. Prompt-injection scanning is on by default; high-confidence system-override patterns force a `block` at guard time and weaker ones raise a `warn`. And autonomy is treated as a number: each action carries the agent's stated confidence, declared on the guard call before the act, and the ledger scores it against the reported outcome so an overconfident agent shows up as a figure on `/decisions`. The confidence value is a prediction, not a postscript, which is the only version of that signal worth recording.

Quick start: npx dashclaw up and a first governed action

The README's quick start is a single command that provisions an embedded Postgres and needs no account.

npx dashclaw up      # no account, first caught action in minutes

For a non-interactive shell, the README gives an explicit variant, because the plain command prompts and will hang:

npx dashclaw up --yes --no-browser

After that, the API key is written to `~/.dashclaw/instance.json`. The README gives two checks: `GET http://localhost:3000/api/health` and `npx dashclaw doctor`. The full runbook is published at `dashclaw.io/llms.txt`. Note the README's own warning that the hosted trial should not be attempted headlessly, since its captcha needs a human.

The repository also ships `examples/first-governed-action.js` and `examples/first-governed-action.py` for the first real call, plus `examples/guard-and-act.js` and `examples/approval-flow.js`. Those files are the right place to start rather than the SDK reference, because the guard call is where the confidence value and the policy evaluation are wired in. For a self-hosted deployment you can instead bring your own Postgres: `docker compose up -d db` starts Postgres 16 on host port 5433 with user, password and database all set to `dashclaw`, and `.env.example` lists the required variables, including `DATABASE_URL`, `DASHCLAW_API_KEY`, a 32-character `ENCRYPTION_KEY`, `NEXTAUTH_URL` and `NEXTAUTH_SECRET`. The compose file's own comment is explicit that it provisions local Postgres only and is not a production deployment path.

Cooperative enforcement is the limitation that matters

The fail-closed guarantee is scoped to specific seams, and the README says so. If you integrate through the Node or Python SDK, a plain REST call, or an ordinary MCP server, DashClaw evaluates and records the action but cannot cancel it. The caller must honor the verdict. A team that reads the headline promise and then wires up the REST API will get logging and policy evaluation, not interception, and the difference will only become visible the first time an agent ignores a block.

The second constraint is evidentiary. Receipts verify their signed contents, not that an external effect occurred. If your compliance story needs proof that a database row was deleted or a push reached the remote, DashClaw's ledger is not that proof. The README separates authenticated identity and action-payload signing for exactly this reason.

Third, the enforcement liveness probe is self-reported. A probe tests whether a synthetic held action executes through the installed hook path, and setup distinguishes stale, broken and unavailable evidence, but the README describes the runtime versions and hook fingerprints as client-reported diagnostics, not attestation. That is an honest framing and also a real ceiling: a compromised or misconfigured client can report whatever it likes.

Finally, this is the wrong tool if you want isolation rather than approval. It will not contain a process that has already escaped its intended scope. It governs calls that flow through it.

Compared with a general policy engine such as Open Policy Agent

The obvious alternative is a general-purpose policy engine like Open Policy Agent, and the difference is where the decision lives. OPA evaluates policy over structured input and returns a decision; it is agnostic about what happens next and has no concept of a pending human approval, an approvals inbox, a phone PWA, or a signed decision ledger. You would build the interception, the notification channel and the record yourself, and you would own the fail-open versus fail-closed question in your own integration code.

DashClaw ships those pieces as one product, with the agent runtimes treated as first-class targets rather than generic callers. The trade is that its policy surface is narrower than Rego and its enforcement is limited to the hook paths it supports. If your governance rules are complex and your enforcement points are already instrumented, a policy engine plus your own plumbing may fit better. If your problem is that a Claude Code or OpenClaw agent runs overnight and nobody is there to say no, DashClaw is aimed directly at that, and the calibrated-interruption feature, where your approve and deny verdicts tune how often it interrupts with a stated cap on false interruptions, has no equivalent in a bare policy engine.

Licence, maintenance and what an upgrade costs you

DashClaw is MIT licensed, and the README states that self-hosting is MIT-licensed while hosting and provider usage are subject to their plans and limits. For a team embedding it in a product, MIT is permissive; the practical question is not the licence text but the operational surface. The platform runs on Node 20 or later, needs Postgres, and requires an `ENCRYPTION_KEY` and `NEXTAUTH_SECRET` that you generate and keep. Losing the encryption key means losing access to whatever it protects, so key custody is part of the deployment, not an afterthought.

Maintenance signals are strong. The last push to the default branch was on 2026-09-15, and the release cadence is fast: platform-v5.37.0 landed on 2026-09-14, platform-v5.36.0 on 2026-09-06, and platform-v5.34.0 the same day as v5.36.0. The repository ships a public maintainer log at `docs/maintainer-log.md`, which is unusual and useful for judging whether a given change affects your integration. The cost of that cadence is that a self-hosted instance will want a deliberate upgrade habit rather than a pull whenever convenient, because the schema is managed through Drizzle migrations and the package exposes `db:migrate` and a `release:check` script. The `doctor` command exists to tell you when your instance has drifted.

This is not legal advice. If you redistribute a modified instance, read the MIT terms and the provider agreements for whatever database and notification channels you connect.

Editorial conclusion

Adopt DashClaw if you run Claude Code, Codex, Hermes or OpenClaw agents unattended and need a human verdict plus a recorded decision trail before destructive calls execute. Do not adopt it if your integration path is a bare SDK or plain REST call and you expect the library itself to stop the action, because those paths only evaluate and record. Verify first that your agent's hook path is one of the enforced seams, run the liveness probe to confirm a held action is actually intercepted, and decide before you rely on it whether Ed25519 receipts and the signed ledger satisfy whoever will audit the run.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ucsandman/DashClaw on GitHub