ConnectR

Ein gemeinsames Gehirn für all deine KI-Codierungsagenten.

ConnectR ist ein lokaler MCP-Server, der Claude Code, Codex, Cursor, Kiro, Gemini CLI und Antigravity einen einzigen Ort zur Koordination bietet: ein Aufgabenbrett, ein Speicher und beratende Dateianspräche – damit mehrere Agenten gleichzeitig am selben Repository arbeiten können, ohne Arbeit zu duplizieren oder sich gegenseitig zu überschreiben.

Claude Code ─┐                       ┌─ shared ticket board
   Codex ────┤──▶ connectr MCP server ─┼─ shared facts/decisions memory
  Cursor ────┤      (one JSON store)   └─ advisory file claims
Kiro/Gemini ─┘        Antigravity ──┘

Warum

Starte zwei Codierungsagenten auf demselben Repository und sie kollidieren: Beide bearbeiten dieselben Dateien, beide erledigen dieselbe Aufgabe, und keiner weiß, was der andere gelernt hat. ConnectR behebt das mit gemeinsamem Zustand statt gemeinsamem Prozess – jeder Agent verbindet sich über die MCP-Tools, die er bereits spricht, mit demselben winzigen Speicher.

Das Protokoll (injiziert in die Anweisungsdatei jedes Tools durch connectr init):

1. Prüfe, bevor du beginnst – board_view + recall für offene Arbeiten und frühere Entscheidungen

2. Beanspruche, bevor du baust – kein Code, bis ticket_claim erfolgreich ist; Live-Besitzer blockieren doppelte Ansprüche

3. Behalte, was wichtig ist – Fakten, Entscheidungen und Lehren (Fehler → Ursache → Lösung) über remember, durchsuchbar mit recall; Fast-Duplikate werden abgelehnt, und jedes whoami zeigt die neuesten Lehren, damit kein Agent einen Fehler wiederholt, den ein anderer bereits bezahlt hat

4. Kündige deine Änderungen an – claim_files warnt andere Live-Agenten vor deinen Pfaden

5. Schließe mit Beweisen ab – Testausgabe / Commit-SHAs über ticket_update, dann ticket_close + Auflösung

Related MCP server: mcp-coordinator

Installation und Verwendung

npm install -g connectr-mcp

Ein brandneues Projekt starten? Lass ConnectR das Orchester zusammenstellen:

connectr new my-app --plan brief.md   # folder + PLAN.md + suggested tools, one brain

new liest deinen Plan, erkennt, was installiert ist, und schlägt vor, welche Tools dieses Projekt benötigt – Dispatch-CLIs, die pro Bereich zugeordnet werden (Backend→claude-code, Skripte→codex, Doku→gemini) und installierte IDEs (Cursor/Kiro/Antigravity), die als Teilnehmer über MCP beitreten. Bestätige oder überschreibe (--tools claude-code,codex), und es verdrahtet nur diese, speichert den Plan in den Prompt jedes entsandten Agenten und erstellt Ticket #1: "Zerlege PLAN.md in Tickets" – führe es aus und das Brett füllt sich von selbst.

In einem bestehenden Projekt, an dem mehrere Agenten arbeiten:

connectr init          # wires project-scope configs: .mcp.json (Claude Code),
                       # .cursor/mcp.json, .kiro/settings/mcp.json,
                       # CLAUDE.md / AGENTS.md / GEMINI.md protocol blocks,
                       # Cursor rules + Kiro steering docs
connectr init --global # also wires Codex (~/.codex/config.toml),
                       # Gemini CLI (~/.gemini/settings.json),
                       # Antigravity (~/.gemini/antigravity-ide/mcp_config.json)
connectr doctor        # verify wiring
connectr plan "add JWT auth, tests for it, and update the docs"   # describe an outcome
connectr plan "..." --run                                # ...and dispatch what it plans
connectr task add "fix the auth flow"                    # auto-routed to the best tool
connectr task add "migrate db" --tool codex --model gpt-5-codex   # manual tool + model
connectr run           # dispatch open tasks to their routed tools, in parallel
connectr routes        # learned routing: how past outcomes reshape where tasks go
connectr dash          # live TUI host: a add task · r dispatch · l tail run log · q quit
connectr ui            # the same host as a local web dashboard (http://127.0.0.1:4270)

connectr ui bedient ein Dashboard ohne Abhängigkeiten, das an localhost gebunden ist: das Ticketbrett als Kanban-Spalten, Live-Agenten, gemeinsamer Speicher mit Lektions-Badges, Dateiansprüche und Run-Log-Enden – live über SSE aktualisiert. Füge Aufgaben hinzu (gleiche @tool:model-Syntax) und entsende offene Tickets aus dem Browser; der Dispatch zeigt immer zuerst den Plan und den Berechtigungsmodus und fragt dich um Bestätigung.

connectr plan ist die Eingangstür: Du beschreibst ein Ergebnis, und ConnectR parkt es als Planer-Ticket auf dem Brett und entsendet es. Der Agent, der es beansprucht, liest dein Repository, das Brett und den gemeinsamen Speicher und erstellt dann die echten Tickets – so betitelt, dass sie gut geroutet werden, mit Verträgen, die für das Ticket veröffentlicht werden, gegen das ein anderes bauen wird. Du schreibst nie ein Ticket von Hand. Im Web-Dashboard ist dasselbe der Plan it-Button (Enter); Add as one task (Umschalt+Enter) ist die Notluke, wenn du bereits genau weißt, was du willst.

Im Dash öffnet a ein Eingabefeld – title routet automatisch, title @codex:gpt-5-codex weist Tool und Modell manuell zu. r zeigt den Dispatch-Plan und den Berechtigungsmodus; erneutes Drücken von r bestätigt. Agenten starten abgekoppelt, sodass sie weiterarbeiten, nachdem du das Dash verlassen hast.

Konten und Abonnements

Es gibt nichts zu verbinden. ConnectR hat keine Konten, keine API-Schlüssel, kein OAuth, keinen Anmeldebildschirm. Es entsendet Arbeit, indem es die bereits installierte CLI als untergeordneten Prozess ausführt – dieser liest seine eigenen Anmeldedaten von seinem eigenen Ort in deinem Home-Verzeichnis:

Die Einrichtung ist also: Installiere ein Tool, melde dich einmal so an, wie du es normalerweise tust, fertig. ConnectR sieht, speichert oder überträgt nie eine Anmeldedatei – das Einzige, was es damit tut, ist zu prüfen, ob die Datei existiert, um dir zu sagen, dass ein Tool bereit ist.

Das ist auch der Grund, warum es nichts zusätzlich zu dem kostet, was du bereits zahlst: Da die Arbeit über die CLIs läuft, wird sie gegen dein bestehendes Claude Pro/Max, ChatGPT Plus oder Google-Abonnement abgerechnet, nicht über nutzungsbasierte API-Gebühren.

Prüfe die Bereitschaft, bevor du entsendest:

connectr doctor

tools:
  [x] claude-code   dispatch     installed · signed in
  [x] codex         dispatch     installed · signed in
  [ ] gemini        dispatch     signed out - run: gemini
  [x] cursor        participant  joins the brain over MCP

Ein Tool, das keine Anmeldedatei deklariert, meldet "Anmeldung nicht überprüfbar", anstatt zu raten – wenn ein Tool seine Anmeldedaten in einem OS-Schlüsselbund aufbewahrt, sagt ConnectR das, anstatt einen Zustand zu behaupten, den es nicht verifizieren kann.

Ein weiteres Coding-Tool hinzufügen

ConnectRs Tools sind Daten, kein Code. Die drei unten sind eingebaut; alles andere, was du ausführst, ist ein JSON-Objekt in .connectr/config.json unter tools – kein Fork, kein PR, kein Neubau:

{
  "tools": [
    {
      "id": "opencode",
      "kind": "dispatch",
      "bin": "opencode",
      "args": ["opencode", "run", "{mode}", "{prompt}"],
      "modelArgs": ["--model", "{model}"],
      "modes": { "safe": [], "auto": [], "yolo": ["--yolo"] },
      "prompt": "arg"
    }
  ]
}

Ein participant-Eintrag benötigt nur id, kind und homeDir (der Ordner, dessen Vorhandensein bedeutet, dass es installiert ist) – er wird mit dem gemeinsamen Gehirn verdrahtet und erscheint im Orchester.

Einem Eintrag die id eines eingebauten Tools zu geben, ersetzt es – so änderst du Flags für ein Tool, das ConnectR bereits kennt, ohne auf ein Release zu warten.

Verifiziere ein neues Tool, bevor du ihm echte Arbeit anvertraust:

connectr task add "cli/script: hello world" --tool opencode
connectr run --dry-run          # confirm it routes
connectr run                    # then read .connectr/runs/*.log

Die erste Zeile jedes Run-Logs ist der genaue Befehl, den ConnectR gestartet hat, sodass ein falsches Flag auf einen Blick erkennbar ist. Nur claude-code, codex und gemini sind hier gegen echte Installationen verifiziert – behandle jede Voreinstellung, die du findest (einschließlich der obigen), als Ausgangspunkt, den du auf deiner eigenen Maschine prüfst.

Dispatch-Berechtigungsmodi

Entsandte Agenten laufen unter einem projektspezifischen Profil (Standard auto – niemals yolo, es sei denn, du sagst es):

connectr init --mode safe|auto|yolo    # saved to .connectr/config.json

In safe/auto schlagen Aktionen, die die eigenen Einstellungen eines Tools nicht erlauben, einfach fehl, anstatt zu fragen – nicht-interaktive Agenten können nicht auf Eingabeaufforderungen antworten. Erlaube projektspezifische Befehle (Testläufer usw.) in den eigenen Einstellungen jedes Tools, wenn du möchtest, dass auto-Agenten ihre Arbeit verifizieren.

Starte deine Coding-Tools neu, damit sie die neue MCP-Konfiguration übernehmen. Sag dann einfach einem Agenten:

"Nutze connectr: whoami, schau auf das Brett, beanspruche ein Ticket und starte."

Die 10 MCP-Tools

Routing ist ergebnisgelernt, bis auf das Modell. Jedes geschlossene Ticket zeichnet auf, welches Tool – und welches Modell, da Agenten ihres melden – welche Kategorie von Arbeit abgeschlossen, fehlgeschlagen oder verloren hat. Mit 3+ Ergebnissen in einer Kategorie übernimmt ein Ziel, das die statische Regel übertrifft, und das kann ein anderes Tool oder ein anderes Modell desselben Tools sein:

◆ docs|readme|research|…
    rule says gemini · outcomes: gemini:gemini-2.5-pro 3w/0l · gemini:gemini-2.5-flash 1w/1l
    pick: gemini:gemini-2.5-pro  << LEARNED override

Zwei Wächter halten es ehrlich: Eine Überschreibung benötigt 3+ Ergebnisse, und sie benötigt, dass das eigene Tool der Regel tatsächlich ausprobiert wurde – sonst würde "nie versucht" als "schlechter als der, der zuerst lief" gelesen und der Router würde versteinern. connectr routes zeigt die gesamte Tabelle mit ihren Beweisen. Deine Brett-Historie entscheidet, was bei was am besten ist, in deinen Projekten. | ticket_create / ticket_claim / ticket_update / ticket_close | Arbeitskoordination; Anspruch vor dem Bau | | board_view | alles auf einen Blick | | claim_files / release_files | beratende Sperren, laufen nach 2h automatisch ab |

Ticket-Schließung erfordert eine Auflösung – completed, duplicate, wontfix oder already_done – damit "geliefert" von "stellte sich als unnötig heraus" unterscheidbar bleibt.

So funktioniert es

• Speicher: <projekt>/.connectr/store.json – menschenlesbares JSON, standardmäßig gitignoriert.

• Parallelität: prozessübergreifende Sperrdatei (O_EXCL, Stale-Steal nach 10s) + atomare Temp-Rename-Schreibvorgänge. Überlebt Abstürze; abgelaufene Ansprüche werden automatisch entfernt.

• Identität: CONNECTR_AGENT-Umgebungsvariable, sonst der Name des MCP-Clients, sonst anon-<pid>.

• Transport: stdio – der eine Transport, den jedes aufgeführte Tool nativ unterstützt. Kein Daemon, nichts zu deployen.

Verifizierte Matrix

Konfigurationsziele, die gegen echte Installationen auf Windows verifiziert wurden:

init ist chirurgisch und idempotent: Es fügt nur seine eigenen markierungsumschlossenen Blöcke und seinen eigenen connectr-Eintrag hinzu/aktualisiert sie – berührt nie Einträge oder Geheimnisse anderer Server.

Entwicklung

npm install
npm test        # vitest suite incl. two-process race test
npm run smoke   # drives two real MCP client sessions over stdio:
                # cross-process memory recall + live-ticket conflict refusal
npm run build && node dist/cli/index.js init --dry-run

Lizenz

MIT