Why I built Derbent

I use more than one coding agent on the same repositories. Claude Code works on one thing, Codex on another, and now and then I ask Copilot CLI something. Each of them is good at its job, and none of them knows what the others did.

What Claude Code learned an hour ago about why a table looks the way it does, Codex has no idea about. There is no single record of which agent ran which command. Every CLI has its own list of MCP servers, so I connect GitHub four times. And if I want an agent to ask me before it runs git push, I have to set that up in four places, four different ways.

Derbent is the tool I wrote to pull that together. It is free and open source.

What it does

Derbent is a gate between coding agents and their tools. Claude Code, Codex, GitHub Copilot CLI and Antigravity CLI connect to it as one ordinary MCP server, and your own MCP servers sit behind it. Every tool call passes through the gate, and four things happen there.

Shared memory. The agents get memory_write, memory_search and memory_read. A note one agent writes in a repository, another agent working in the same repository can find. Search is full-text, and a git worktree shares the memory of the repository it was added from.

Rules. Allow, deny or ask, by agent, tool and argument. Rules are tried in order and the first match wins. A tool an agent may not use is not even listed to it, and calling it by name is refused anyway.

Approvals. A call that hits an ask rule waits until you decide. Run derbent in a terminal of its own and the waiting calls are at the top: approve once, approve for the rest of that agent's session, or deny. The same works from any shell with derbent approve 12. If nobody answers, the call is denied when the timeout runs out, and the agent is told why.

Receipts. Every call that passes through the gate leaves a receipt: which agent, which tool, which arguments, what was decided and what came of it. The receipts form a hash chain, and derbent verify tells you whether one was edited or removed. Secrets are masked before anything is stored.

The agents' own tools, their shell commands and file edits, don't go through MCP. But all four CLIs can run a command of your choice before each tool call. Make that command derbent gate, and a git push goes through the same rules, the same approval and the same receipt chain.

The name

In Turkish history, a derbent was a guarded post on a mountain pass or a dangerous road. The men who kept it were responsible for the pass, and in return were spared some taxes. They decided who went through and kept a record of everyone who did.

Every English word I tried (gatekeeper, warden, checkpoint, bastion) was either another security product's name or too general. Derbent says exactly what the tool does, and nobody else uses it.

How it is built

The most important decision is that there is no daemon. The obvious shape is a hub every agent connects to, but that hub has to start before any agent, stay alive, restart after a crash, and guard the port it listens on. In Derbent every agent session starts its own gate process, and they all open the same SQLite file. Nothing has to run first, there is no open port, and a crash takes down one agent's gate, not everyone's.

That has a price, and the documentation says so: every agent session starts its own copy of the servers behind the gate, and approvals are noticed by polling rather than instantly.

It is written in Go. Claude Code starts derbent gate once for every tool call, so every shell command waits for a process to start, decide and exit. A Go binary starts without loading an interpreter, and it is one file for Windows, macOS and Linux that asks for nothing else on the machine.

What it does not do

Writing down what Derbent doesn't do mattered as much as what it does.

• The agent name is a label, not authentication. Any process running as you can call itself anything.
• It is not a boundary against an agent that already has a shell as you. Such an agent could run derbent approve itself, or write the database. Approvals guard against mistakes and against prompt injection that stays inside MCP.
• The chain doesn't catch everything on its own. It finds changes in the middle; a cut-off tail or a chain rewritten from the start only shows against a copy of the head hash you keep somewhere else.
• Glob rules don't understand shell syntax. git push* doesn't match cd repo && git push.

The worst thing a security tool can do is promise more than it does. Used knowing its limits, Derbent helps a lot; trusted without knowing them, it would do harm.

Try it

go install github.com/tunahanaliozturk/derbent/cmd/derbent@latest

claude mcp add derbent -- derbent mcp --agent claude
codex mcp add derbent -- derbent mcp --agent codex

With just that, the two agents share one memory and every call is recorded. The documentation covers rules, approvals and the hooks.

If you use more than one coding agent, I would like to hear from you, especially about which calls you would want held for approval. Issues and ideas are welcome on GitHub.