git-bug-broker
An MCP server that lets several agents file, label and close issues in one git-bug store (a distributed issue tracker that keeps issues in git refs) while its web UI stays open.
git-bug keeps issues inside the repository as git objects, so agents can track work
next to the code with no hosted tracker, API token or network. Through this server an
agent can open an issue for a bug it finds, comment on it as it investigates, label it,
read what other agents have written, and close it with a note naming the commit that
fixed it. Issues are versioned like commits and sync through any git remote with
git bug push and git bug pull, so the record carries over between sessions and
between agents.
git-bug webui holds the search index for as long as it runs, and every CLI command waits on it without saying so. The broker talks to the web UI's GraphQL endpoint instead, takes a file lock for each write, and refuses any write that breaks the project's conventions: claim-style titles, one area/ and one kind/ label, required body sections. A rejected write lists every problem at once. Unlike a wrapper around the CLI, it keeps working while git-bug webui is open, and concurrent writes don't collide. The client is also a small Python library, so a script can write to the store while the UI is open too.
Works with git-bug 0.11. Tested on Windows; the Linux and macOS paths are written but untested.
Install
pip install git-bug-broker
or from a checkout of the repository, pip install -e .. Needs Python 3.10+ and git-bug on PATH.
Run
git-bug-broker-start <repo> # start the web UI (reuses one already running)
git-bug-broker-start <repo> --status
git-bug-broker-start <repo> --stop
It prints the web UI's URL. An issue is at <url>/_/issues/<id>, where <id> is the
short id the tools return. The issue list starts filtered to status:open; clear the
search box to see closed issues too. --stop only stops the process it started.
Use from Python
from git_bug_broker.client import Client
c = Client(repo="/path/to/repo")
c.file_entry(
"The retry loop never backs off after a 429",
"**What** retry() sleeps a fixed 1 s.
**Done when** the delay doubles per attempt.",
["area/api", "kind/defect"],
)
Connect an MCP client
.mcp.json for Claude Code:
{
"mcpServers": {
"git-bug": {
"command": "git-bug-broker",
"env": {
"GITBUG_BROKER_REPO": "/path/to/repo",
"GITBUG_BROKER_RULES": "/path/to/repo/.git-bug-rules.json"
}
}
}
}
Any stdio MCP client takes the same command and env.
GITBUG_BROKER_RULES is optional. Without it the defaults in
src/git_bug_broker/rules/default.json apply and any area name is accepted.
examples/rules.example.json shows a project file with a fixed area list.
GITBUG_BROKER_URL points the client at a web UI the broker did not start, for example one on another port.
Tools: file_entry, comment, edit_body, edit_comment, relabel, set_status,
set_title, get, query. A rejected write lists every problem at once.
Rules
What gets checked is in CONVENTIONS.md. Briefly:
- a title is a claim about the code, at most 80 characters, with no leading number
- exactly one
area/and onekind/label, with a slash, never a colon - defects and chores have
WhatandDone whensections
Why the lock
git-bug 0.11 applies an operation and commits it in two unguarded steps. When two
writes hit the same issue at once both land, but one caller is told
can't commit an entity with no pending operation, and a retry duplicates the write.
The broker holds <repo>/.git/git-bug-broker/write.lock for each write. Reads don't
lock.
Measured on git-bug 0.11 on Windows: with the lock, 24 parallel writes from 4 server processes, 12 of them to one shared issue, finished in 3.7 s with no errors. Without it, 28 of 30 concurrent writes to one issue reported failure although all 30 had landed.
Limitations
- The web UI has to be running. If it isn't, every tool says so and nothing is queued.
- Filing an issue is two mutations, create then label. A crash in between leaves an unlabelled issue; the error gives its id.
- The web UI binds to 127.0.0.1 with no authentication.
- Edits made in the web UI aren't checked against the rules.
- Free-text search returns at most 10 results.
title:,label:andstatus:filters return everything.
Development
pip install -e .[dev]
pytest
tools/view.py renders the store as a static HTML page and a JSON Lines snapshot. It reads through the CLI, so run it while the web UI is stopped; anything reading its output needs neither.
License
MIT
Release files for git-bug-broker 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| git_bug_broker-0.1.0.tar.gz | 16.3 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| git_bug_broker-0.1.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 31.8 kB
Release files / git_bug_broker-0.1.0.tar.gz
| Download URL | git_bug_broker-0.1.0.tar.gz |
|---|---|
| Size | 16.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
a25d1d2382ecb2b174a64311767ceffa3b9355501d9daf0af6543f81345bb8ab
|
|
BLAKE2b-256 checksum How to use checksums |
1df5e4d9bd6477e8cf3b79bad642fde9d7c716f2fa7b0ebd6887ef9004f30208
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 25, 2026.
Transparency logRelease files / git_bug_broker-0.1.0-py3-none-any.whl
| Download URL | git_bug_broker-0.1.0-py3-none-any.whl |
|---|---|
| Size | 15.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
27f9d9dde8fa3eeb6fd64c755d4b18c42262f29231495a2bd6cc69bdefa98ce4
|
|
BLAKE2b-256 checksum How to use checksums |
7ea99264d543f297daf559d9a5bede87d6809d9a03be4185ad0a920fa7158785
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 25, 2026.
Transparency log