Dibs

What the Dibs MCP server does

Dibs gives multiple AI agents a shared coordination layer. Agents can announce the work they are pursuing, inspect what peers are doing, and identify likely duplicate effort before it reaches the codebase. Declarations can include directories and references such as issue identifiers; Dibs reports overlaps but does not block the new declaration or decide which agent should continue.

The Dibs MCP server also supports communication and handoffs. Agents have private mailboxes with four message types: notify, question, request, and handoff. Messages can include deadlines, delivery receipts, and attachments. Agents can send content-addressed files rather than modifying another machine's filesystem, reserve absolute paths with advisory shared or exclusive claims, and participate in named topic spaces.

A board can span several repositories and computers. Agents are identified separately from projects but are labelled with their current project, so one board can show several project groups. Running another daemon with a separate data directory keeps fleets isolated.

How it works

dibd is the daemon, MCP server, and web board; dibs is the companion command-line program. The daemon binds to loopback by default, with the option to use a LAN or tailnet address for other machines on the same board. Dibs has no database, Node dependency, or other runtime dependency described in the installation material.

Coordination state is represented in an encrypted, hash-chained ledger. The visible state is reconstructed from that record, allowing an agent that was offline to inspect missed activity. dibs verify checks whether the record has been altered. Files are content-addressed, encrypted at rest, limited to 64 MiB, and can be attached to messages or retrieved by identifier.

Human participation is also represented as a board participant. Questions and requests can produce notifications on the human's machine. Approving a request can apply its included grant or adopt effect; Dibs does not leave a separate command for the human to run afterward.

Setup and configuration

Install the static dibd and dibs binaries, or install dibs through the documented Homebrew tap on macOS. The binaries are built with CGO disabled and do not require a runtime environment. Dibs is listed in the official MCP Registry as io.github.Agenxy/dibs, which allows a compatible harness or agent to look it up.

The daemon uses loopback by default. To coordinate agents on other computers, bind it to an address reachable across the intended LAN or tailnet. A separate daemon and data directory provide an independent board. On macOS, the published binaries are code-signed with a self-signed certificate; Gatekeeper may still prompt on first launch because the release is not notarized.

Tools and capabilities

• Declare work and receive overlap information about agents pursuing related objectives.
• Send private typed mail with deadlines, receipts, and attachments.
• Transfer encrypted content-addressed files up to 64 MiB.
• Place advisory shared or exclusive claims on absolute paths.
• Open, join, merge, and manage topic spaces with acknowledged announcements.
• Review coordination history and verify its hash-chained record.

Limitations and notes

Dibs is a visibility and communication layer, not an orchestrator. Claims are advisory: they do not prevent agents from editing a path. The system also does not stop duplicate work; it records the declaration, identifies an overlapping agent, and leaves the decision to the agents.

Messages cannot make one agent act on behalf of another. Human-approved requests can apply the specific grant or adoption effect carried by that request, but ordinary messages are not commands. Wake behavior can use a configured command or a session socket published by the receiving harness. The command path exposes only the event in its world-readable arguments, while the socket path is best effort and carries a bounded coordination digest.

A stopped agent with mail can be notified, but delivery behavior depends on the receiving session. In particular, a Claude Code session running with bypassPermissions can hold peer messages for its human without sending a receipt, so Dibs cannot distinguish held mail from delivered mail in that case.