DashClaw Adds Remote Approvals to Agents
DashClaw is ucsandman’s open-source TypeScript project for putting policy checks and remote approvals in front of unattended coding agents. The uncomfortable moment when an agent is allowed to keep working after you leave, but may still try to delete files, spend money, or run a destructive command. Unattended agentic coding needs a pre-execution stop sign, not just a nicer post-run summary.
DashClaw is a policy and approval layer for coding agents: it pauses selected tool calls before they run, routes the decision to an approval inbox, and records the result in a signed ledger. As of the September 2026 source snapshot, the repository had 299 GitHub stars, an MIT license, and listed integrations or targets including OpenClaw, Hermes, Claude Code, and Codex.
Why developers cared about this one
The interesting part is not that DashClaw says “governance.” Lots of tools say that. The interesting part is where it puts the control point.
The README describes a hook-integrated flow: an agent tries a destructive or expensive tool call, DashClaw freezes it before execution, a human approves or denies it remotely, and the decision becomes replayable evidence. That is a sharper boundary than asking the model to “be careful” in a prompt.
For Claude Code this maps to a real pain. You may trust it to edit tests, refactor a module, or open a pull request. You may not want it to run rm -rf, rotate infrastructure, push to main, call a paid API loop, or rewrite a migration while you are making coffee.
The Hacker News-shaped appeal is easy to understand. Developers want agents to be useful while unattended, but they do not want to hand them unconditional authority. DashClaw tries to preserve the useful part of autonomy while making the dangerous part interruptible.
Don't assume “approval layer” means “safe by default.” DashClaw’s own framing depends on supported enforcement integrations. If an agent path is not actually routed through the enforcement point, the approval inbox is just decoration.
The boundary has to sit before execution
DashClaw is most interesting as an execution boundary. It is not just a log viewer. It is meant to catch a risky action before the shell command, file write, API call, or tool invocation actually happens.
That matters because code review guardrails often arrive too late. A pull request can show you the diff after the agent has already deleted a fixture, rewritten local secrets, or run a migration against the wrong environment. Good review still matters, but it is not the same as stopping the action.
A Claude Code example makes the shape concrete. Imagine a repo rule that says the agent can edit src/** and tests/**, but any command touching db/migrations/**, .github/workflows/**, or deployment scripts needs a human approval. DashClaw’s value is in turning that rule into a runtime pause instead of a paragraph in CLAUDE.md that the model might obey most of the time.
A small hook boundary might look like this in plain English:
Allow without approval:
- read files
- edit src/**
- edit tests/**
- run npm test or npm run lint
Require approval:
- delete files
- edit db/migrations/**
- edit .github/workflows/**
- run deploy, terraform, kubectl, or paid batch jobs
- push branches or tags
Don't make the boundary so broad that every useful action blocks. If every test run needs approval, the agent becomes a very expensive notification system. Start with destructive, irreversible, or expensive actions.
What DashClaw is not trying to be
DashClaw is not a replacement for code review, sandboxing, or good repository rules. It sits in the middle of the agent loop and asks for permission when a configured action crosses a line.
That distinction is healthy. A sandbox limits blast radius. A review checks the final patch. A concise repository memory tells the agent what conventions matter. DashClaw’s lane is the approval moment before a risky action executes.
This also explains why the project feels adjacent to MCP, the Model Context Protocol. MCP is becoming the integration layer for tools such as GitHub, issue trackers, databases, and private knowledge systems. The more power an agent gets through tool connections, the more valuable a boring approval checkpoint becomes.
For readers following AI coding governance, DashClaw is a useful concrete specimen. It shows AI coding governance as a runtime design problem, not just a policy document.
Don't treat signed evidence as magic. A signed ledger helps answer “who approved what, and when?” It does not prove that the underlying policy was complete, that the integration covered every path, or that the approved action was wise.
When to try it, and when to skip it
Try DashClaw when you already have an unattended or semi-unattended agent doing real work. The sweet spot is a repo where the agent can safely make progress on ordinary edits, but occasionally needs to cross a boundary that should wake a human.
It is especially interesting for overnight maintenance branches, dependency-update agents, test-repair loops, and internal tools where a bot may need to run commands while the developer is away. You want the agent to keep momentum, but not enough momentum to mutate production-adjacent systems without a receipt.
Skip it for tiny experiments where the agent only edits a disposable branch in a disposable repo. Also skip it if you cannot identify the dangerous actions. “Ask me before anything important” sounds safe, but it usually means nobody has written down what important means.
This is also where DashClaw differs from projects that keep secrets out of prompts, such as Keyclasp Keeps Tokens Out of Prompts. Token isolation reduces what the agent can see. DashClaw focuses on what the agent can do.
The practical bet is not that every coding agent needs DashClaw. The bet is that unattended coding agents need at least one real pre-execution control if they can touch expensive, destructive, or externally visible systems.
Try DashClaw safely in a disposable repo
Use a throwaway repository first. The goal is not to prove that DashClaw can guard your whole engineering system in one afternoon. The goal is to see whether the approval loop catches the one action you actually care about.
From the project README, the local non-interactive setup path is:
npx dashclaw up --yes --no-browser
Then verify the local instance before connecting an agent:
curl http://localhost:3000/api/health
npx dashclaw doctor
A small first test can be this:
| Test | Good fit | Not a good fit |
|---|---|---|
| Delete a generated file | Approval should pause before deletion | Deletion happens before the inbox sees it |
| Edit a migration | Human sees the file path and command intent | Agent rewrites migration silently |
| Run tests | Usually allowed without approval | Every normal test run blocks |
| Push a branch | Approval required if your policy says so | Agent can publish without a decision record |
Keep the first policy intentionally small. One destructive command, one sensitive path, and one ordinary allowed command are enough to learn whether the integration is enforcing or merely observing.
Watch for testing only happy paths. A good first experiment includes a denied action. You want to know what the agent does after “no”: stop cleanly, choose a safer alternative, or keep trying the same blocked call.
Further reading
Next step
Pick one action your coding agent should never take silently, then test whether your current setup stops it before execution. If the answer is “we only find out in the diff,” DashClaw is worth a small disposable-repo experiment.