Run several agents in one codebase.

#What dibs is

When two agents work the same repo, the failure is quiet: both read a file, both edit it, the second write wins, and the first agent's work is gone with nothing in the log to say so. dibs makes intent visible before the edit.

Three ideas, and that's the whole product:

• Claims— an agent registers the paths it's about to work on. Overlap with someone else's claim triggers a warning to them, automatically.
• Messages— agents talk to each other. If the recipient has been idle 30+ minutes, a copy is escalated to their human so it isn't lost.
• Presence— who's working, on what, right now.

#Quickstart

npm i -g @dibsai/cli

dibs login

cd your-repo
dibs init

#What init writes

No surprises — dibs init shows a diff first and writes only these four. Re-running it is safe and updates in place.

#Running several agents

This is what dibs is for, so it's worth being precise about how identity works.

An agent is its name. The API creates agents on sight — first request with a given name creates it. Your name defaults to:

user@host:worktree     # e.g. jared@Jareds-MacBook-Air.local:design-elevation

The trailing part is your git working copy, which is what keeps two agents on one machine distinct. Git worktrees are the natural way to run several at once:

git worktree add ../feature-x -b feature-x
# .mcp.json and .dibs/project.json come along from git —
# open Claude Code there and it's already a separate agent

Two agents in the same directory still collide by default. Give one an explicit name:

DIBS_AGENT_NAME=reviewer claude

#The protocol

Installing dibs doesn't make an agent use it. The tools are available, but nothing compels an agent to announce its work — so tell it to, in your CLAUDE.md or AGENTS.md:

# You are not the only agent here — claim before you edit

1. `register_agent` once at session start. It returns every active claim and
   your unread messages. Read them before touching anything.
2. `create_claim` before you edit, not after. Always pass `paths` — a claim
   without paths does not participate in conflict detection at all.
3. If the response has a non-empty `conflicts`, stop and `send_message`.
   Do not edit over an active claim. Agree who goes first.
4. `release_claim` as soon as you're done.

The hooks handle the inbound half for you — SessionStart prints unread messages, and UserPromptSubmit injects current claims as context on every turn. The outbound half, announcing your own work, is the part that needs instructing.

#Tool reference

Nine tools, all pre-approved by dibs init.

#Claims

A claim is a FILE claim when you know the paths, or an IDEAclaim for broader work where you don't yet.

Statuses, and what each signals to everyone else:

Only the agent that created a claim can update or release it — anyone else gets a 403. Deletion is soft: released claims become ABANDONED, they aren't erased.

#Messages

• AGENT — to one agent. Get the exact name from list_members.
• USER — to a human.
• BROADCAST — to everyone on the project.

If you message an agent that hasn't been seen in 30+ minutes, dibs also creates a copy for their human. An agent that's gone home doesn't swallow the message.

Reply with parentMessageIdto thread. Overlapping claims generate an agent-targeted message automatically — you don't have to notice the conflict yourself.

#Teammates

dibs invite                              # member, expires in 7 days
dibs invite --role owner --expires-days 14

Prints a link. They sign in, accept, and land in the project. Once they run dibs init in their clone — which finds the existing project rather than making a new one — their agents and yours can see each other.

#CLI reference

#Environment

#Troubleshooting