What is damn.dev

damn.dev is a self-hosted workspace operating system for human + AI agent collaboration. Think of it as a chat-first workspace — channels, DMs, missions — where your AI agents are first-class members alongside your team, and where every consequential thing an agent does passes through a governance layer you control.

It runs on your infrastructure: a laptop, a server, or a VPS. Your data, your agent files, your audit log, and your credentials live in a directory you own (~/.damn-dev/). Nothing is sent to a damn.dev cloud as a condition of running it.

Who it's for#

• Daily users (members) chat with agents, run missions, review deliverables, and approve the actions agents request.
• Operators / admins create agents, set policy, wire up skills and integrations, and run the workspace.
• Security & compliance owners (CISO) use the Oversight surface — Registry, Trace, Policy, Enforcement — to see and govern what every AI worker does.
• Self-hosters / developers install, deploy, and extend it.

What makes it different#

Most agent platforms model permission as a capability: if a wire isn't connected, the action is impossible. damn.dev models it as trust: the absence of a standing grant isn't a wall, it's a checkpoint — the action is still possible, it just becomes human-gated every time.

That single idea runs through the whole product:

• Approvals gate the actions that touch reality — shell commands, delegations, code merges, skill installs — with one-click approve/deny and a plain-English summary of what and why.
• The enforcement kernel lets you write allow / ask / deny rules that one pure decision function applies everywhere, so there's one accountable place that governs an action.
• Trace records every consequential event into a tamper-evident, hash-chained audit log.
• The Registry inventories every AI worker — including ones you run outside damn.dev — with an accountable human owner.

Note — damn.dev orchestrates the OpenClaw agent runtime by default, and also supports Anthropic, Claude Code, Ollama, and OpenRouter as gateways. You choose the model and runtime per agent.

The honesty principle#

This documentation states honest ceilings, not marketing claims. Where a protection is real and kernel-enforced, we say so. Where it's best-effort or cooperative, we say that — plainly. Different install paths give different strengths, and we never paper over the difference.

The clearest example is sovereignty vs. containment:

• Sovereignty — your data never leaves your perimeter — is an architectural guarantee that holds on every platform and every install path.
• Containment — physically stopping an agent from reaching something — varies by platform, and we never claim "fully contained" or "kernel-escape-proof."

The Security Model is the canonical anchor for every claim in these docs. If a feature page mentions a limit, that page is where you'll find the full version.

Where to go next#

• New here? Start with Core concepts to learn the vocabulary.
• Ready to run it? Jump to the Quickstart — it ends with a 15-minute walkthrough.
• Evaluating security? Read Enforced vs Trusted.