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. It deals with 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. The useful takeaway is simple: 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, Anthropic’s coding agent, 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.

The trap is assuming “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

The trap is making 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 the related training topic, DashClaw is a useful concrete specimen. It shows ai coding governance as a runtime design problem, not just a policy document.

The trap is treating 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:

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.

The trap is 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.

Common questions

• Can DashClaw make an unattended coding agent safe?

  No, not by itself. DashClaw can pause configured risky actions before they run and record approval decisions, but safety also depends on the agent integration, sandboxing, repo permissions, and review. The key caveat is in its own framing: enforcement requires a supported integration path.

• Does DashClaw replace code review?

  No, it complements code review. DashClaw focuses on the moment before a risky tool call executes, while review evaluates the final code and intent. A useful split is: approvals guard destructive actions, review guards correctness, maintainability, and product judgment.

• How would this fit with Claude Code?

  Use it around the actions you would not want Claude Code to take unattended. A practical boundary is to allow normal edits and tests, then require approval for deletes, migration edits, deploy commands, workflow changes, and pushes. Keep CLAUDE.md concise, but do not rely on memory alone for dangerous actions.

• Is DashClaw overkill for a solo side project?

  Often, yes. If the repo is disposable, has no production credentials, and the agent cannot spend money or publish changes, a branch and a quick diff may be enough. DashClaw becomes more compelling when the agent has durable permissions or can affect shared systems.

• What should I check before trusting the approval inbox?

  Check that the action is blocked before execution, not merely logged afterward. The fastest proof is a disposable test where the agent attempts a denied delete or migration edit. If the file changes before you decide, your enforcement boundary is in the wrong place.

Best ways to use this research

• Best for: evaluating whether an unattended coding-agent workflow needs a runtime approval checkpoint before destructive or expensive actions.
• Best first artifact: a short allow/approval boundary with three categories: ordinary edits, sensitive paths, and external side effects.
• Best comparison angle: compare pre-execution approval against sandboxing, code review, and prompt-based rules; they solve different parts of the risk.
• Best Claude Code experiment: connect only a disposable repo first, then test one allowed edit, one blocked delete, and one denied sensitive-path change.

Further reading

• DashClaw — source
• Claude — Agent
• Model Context Protocol — specification
• Claude Code — hooks

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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.