Clonst – KI-Code-Review-MCP für Claude Code, unterstützt von Codex

Holen Sie sich eine zweite KI-Meinung zu Ihrem Code, bevor er ausgeliefert wird. Clonst ist ein Model Context Protocol (MCP)-Server, der Claude Code mit OpenAI Codex für adversariales Code-Review verbindet: Claude schreibt den Plan oder den Code, Codex kritisiert ihn, Claude überarbeitet, und das Pingpong wiederholt sich, bis beide Modelle einen Konsens erreichen. Es läuft auf Ihrem bestehenden ChatGPT-Abonnement über die offizielle Codex CLI. Keine API-Schlüssel, keine zusätzliche Abrechnung.

Unabhängiges Projekt. Nicht verbunden mit OpenAI ("Codex", "ChatGPT") oder Anthropic ("Claude").

Warum ein zweites Modell?

Ein LLM, das seine eigene Ausgabe überprüft, teilt die eigenen blinden Flecken. Ein zweites Modell, von einem anderen Anbieter, mit eigenem Training und eigenem Gedächtnis, fängt ein, was das erste übersehen hat: falsche Annahmen, fehlende Randfälle, zerbrechliche Migrationen, Race Conditions, Sicherheitslücken. Clonst verwandelt das in eine strukturierte Review-Schleife mit einem harten Ausstiegskriterium: Konsens, nicht Höflichkeit.

Related MCP server: claude-code-codex-agents

Funktionen

• Null Aufwand. Installieren Sie es und vergessen Sie es: Claude löst das Review von selbst aus, und nur wenn die Änderung Ihr Kontingent wert ist.

• Pingpong bis zum Konsens. Standardmäßig unbegrenzte Runden. Strukturierte Urteile (APPROVED / CHANGES_NEEDED), erforderliche Änderungen, Vorschläge, Risiken. Claude kann eine Kritik mit Begründung ablehnen; Codex bewertet die Ablehnung in der nächsten Runde neu.

• Echtes Sitzungsgedächtnis. Codex setzt bei jeder Runde dieselbe CLI-Sitzung fort und merkt sich seine früheren Kritiken. Kein erneutes Senden des Kontexts, kein Goldfisch-Reviewer.

• Ihr ChatGPT-Abonnement, keine API-Schlüssel. Reviews laufen über die offizielle codex CLI und deren vorhandene Anmeldung.

• Wählen Sie Ihren Reviewer. Standardmäßig verwenden Reviews das Modell und den Reasoning-Aufwand, mit dem Ihre codex CLI bereits konfiguriert ist. Eine Zeile in ~/.clonst/config.json gibt Reviews ihre eigene Einstellung (z. B. einen schnelleren, günstigeren Aufwand), ohne Ihre Codex-Erweiterung zu berühren – siehe Konfiguration.

• Kostentransparenz. Der Abschlussbericht zeigt das Reviewermodell, die Runden, die Gesamtdauer und die verbrauchten Token – frische Token hervorgehoben, Cache-Wiederholungen separat aufgeführt, sodass kumulative Summen nie beängstigender aussehen, als sie sind.

• Ein Prüfpfad, der die Konversation überlebt. Jedes Review schreibt einen strukturierten Markdown-Bericht (Zusammenfassung in einfacher Sprache + die Forderungen, Änderungen und Ablehnungen jeder Runde, wortwörtlich) unter ~/.clonst/reports/.

• Absichtsdrift wird als erstklassige Prüfung behandelt. Der Reviewer misst das Ergebnis an Ihrem angegebenen Ziel, nicht nur an technischen Standards – eine „Korrektur“, die stillschweigend das gewünschte Verhalten ändert, wird gekennzeichnet, und Produktentscheidungen werden an Sie weitergeleitet, anstatt von einem LLM entschieden zu werden.

• Pragmatisch von Natur aus. Das Review zielt auf wesentliche Mängel – was den normalen Gebrauch beeinträchtigt, Datenverlust verursacht, ein Sicherheitsloch öffnet oder eine teure Neuschreibung erzwingen würde – nicht auf Vollständigkeit. Seltenheit allein entschuldigt niemals einen schwerwiegenden Mangel, und ein später leicht zu behebendes Detail blockiert niemals Ihre Veröffentlichung.

• Fragen, die Sie tatsächlich beantworten können. Haben Sie die Schleife laufen lassen und den Faden verloren? Jede an Sie gerichtete Frage wiederholt, was gerade gebaut wird, warum sie jetzt auftaucht und was jede Option ändert – in einfacher Sprache, kein Code-Lesen erforderlich.

• Es merkt sich, was Sie ihm sagen. Sagen Sie, ein Review war zu pingelig oder eine Frage ergab keinen Sinn, und Clonst zeichnet es auf – selbst wenn Sie mit Claude statt mit Clonst gesprochen haben. Nichts ändert sich hinter Ihrem Rücken: es zählt, sagt Ihnen, wenn eine Bemerkung immer wieder kommt, und Sie entscheiden, was Sie damit tun.

• Kollateralschäden werden auf beiden Seiten gejagt. Bevor der Reviewer eine Änderung fordert, muss er prüfen, was sonst noch durch diese Änderung kaputtgehen würde (Aufrufer, Verträge, entfernte Module); bevor Claude eine Änderung vornimmt, muss er dasselbe tun – und eine Ablehnung wegen Kollateralschäden kommt mit einer sichereren Alternative, nicht mit einem nackten Veto.

• Ihre eigenen Review-Regeln für Ihr Projekt. Legen Sie eine CLONST.md im Projektstamm ab, und der Reviewer prüft Ihre Konventionen zusätzlich zu seinen eigenen Standards. CLAUDE.md leitet den Autor; CLONST.md leitet den Reviewer.

• Reviews in Ihrer Sprache. Kritiken kommen in der Sprache zurück, in der Sie arbeiten (pro Aufruf oder einmalig für alle mit default_language in der Konfiguration), während das Protokoll maschinenlesbares Englisch bleibt.

• Nichts geht je verloren. Jede rohe Antwort des Reviewers wird vor dem Parsen auf die Festplatte gespeichert.

• Plattformübergreifend. Windows, macOS und Linux, alle drei werden von der CI abgedeckt.

• Abgesichert. Prompt-Injection-Schutz, schreibgeschützte Sandbox, zugelassene CLI-Argumente, hermetische Testsuite (kein LLM-Aufruf, kein Kontingent).

Wann wird es ausgelöst?

Sie müssen nie danach fragen. Claude entscheidet, wann ein Review Ihr Kontingent wert ist, und die Regel lautet: Wichtigkeit, nicht Größe:

Das Pingpong ist standardmäßig unbegrenzt: es läuft bis zum Konsens und meldet sich bei Ihnen alle 5 Runden (konfigurierbar). Und Sie können jedes Review in einfacher Sprache begrenzen: "review this, 3 rounds max".

So funktioniert es

You ── conversation ── Claude (reviser, keeps the conversation context)
                          │
                          │  clonst_review (MCP, one call = one critique)
                          ▼
                       Clonst ── spawn ── codex exec [resume <thread_id>]
                                             (reviewer, keeps its session)

Die Schleife lebt auf Claude's Seite: er sendet ein, Codex kritisiert, Claude überarbeitet in der Konversation (vor Ihren Augen), reicht erneut mit der zurückgegebenen thread_id ein, bis consensus: true. Die Schleife wird vom Aufrufer gesteuert (die thread_id reist mit jedem Aufruf), während der Server pro Sitzung Aufzeichnungen auf der Festplatte führt: vollständige Protokolle, das Urteil der vorherigen Runde für genauen Abruf, die laufende Dauer/Token-Summen und der strukturierte Review-Bericht (bei jeder Runde neu generiert). Codex-Sitzungen bleiben auf der CLI-Seite bestehen.

Schnellstart

Anforderungen:

• Claude Code – die Terminal-CLI oder die VS Code / JetBrains-Erweiterungen, die dieselbe MCP-Konfiguration teilen

• Node.js 22+

• Die Codex CLI, angemeldet mit einem ChatGPT-Plan:

npm install -g @openai/codex
codex login

Clonst installieren (empfohlen, über npm):

claude mcp add clonst --scope user -- npx -y @clonst/clonst

Oder aus dem Quellcode:

git clone https://github.com/capritora/clonst.git && cd clonst
npm install && npm run build
claude mcp add clonst --scope user -- node /absolute/path/to/clonst/dist/index.js

Prüfen Sie die Funktion: Sagen Sie in einer neuen Claude Code-Konversation „ping clonst“. Erwartet: codex_available: true, codex_logged_in: true.

Wie ein Review aussieht

Reviews geschehen von selbst, aber Sie können sie auch steuern:

Schlagen Sie einen Plan für X vor und lassen Sie ihn dann von Clonst bis zum Konsens reviewen.

Lassen Sie diese Migration von Clonst reviewen, maximal 3 Runden.

Bitten Sie Clonst um ein sicherheitsorientiertes Review dieses Authentifizierungsflusses.

Sie sehen jede Überarbeitung in der Konversation, und beim Konsens endet Claude mit einem kurzen Bericht, zum Beispiel:

Clonst-Review: GPT-5.5 (hoher Aufwand), 2 Runden, 5 min 30 s, ~210k frische Eingabe plus 18k Ausgabetoken (kumulative Eingabe 2,8 Mio., davon 2,6 Mio. Cache-Wiederholungen). Der Reviewer forderte eine Anti-Doppelkorrektur-Grenze bei der Migration und ein Timeout für den API-Aufruf, beide umgesetzt. Ich habe einen Vorschlag (außerhalb des MVP-Umfangs) abgelehnt und der Reviewer akzeptierte die Begründung. Vollständiger Rundenbericht: ~/.clonst/reports/2026-07-06-a3f1...md

Möchten Sie die Details Runde für Runde? Fragen Sie einfach („walk me through the rounds“): Claude hat die gesamte Aussprache und berichtet auf Anfrage.

Die Review-Berichtsdatei

Jedes Review schreibt außerdem einen strukturierten Markdown-Bericht unter ~/.clonst/reports/, der bei jeder Runde aktualisiert wird – damit der Prüfpfad die Konversation überlebt. Er beginnt mit der Zusammenfassung in einfacher Sprache (nach dem Konsens wortwörtlich versiegelt), dann ein Abschnitt pro Runde mit den genauen Worten, die jede Partei verwendet hat:

• was der Reviewer forderte, vorschlug und als riskant markierte (wortwörtlich)

• was der Überarbeiter vor jeder Runde als geändert oder abgelehnt erklärte (wortwörtlich)

• Modell, Aufwand, Dauer und Token pro Runde sowie Gesamtsummen des Reviews

• ein Prüfpfad, der auf das Sitzungsprotokoll und die rohe Reviewer-Ausgabe verweist

Die Datei ist eine reine Projektion des serverseitigen Zustands: Nichts wird nachträglich umformuliert, und von einem LLM stammender Text wird maskiert, sodass keine gefälschten Berichtsabschnitte erstellt werden können. Ein Bericht, der mitten in einer Sitzung beginnt (wiederaufgenommener Thread), wird explizit als PARTIAL HISTORY gekennzeichnet. Zwei Kennungen, zwei Aufgaben: report_id benennt die Berichtsdatei, thread_id setzt die Reviewer-Sitzung fort.

Werkzeuge

clonst_ping

Server-Gesundheit: Verfügbarkeit der codex CLI, Version, Anmeldestatus, geladene Konfiguration, Protokollverzeichnis. Verbraucht kein Kontingent.

clonst_review

Eine strukturierte Kritik pro Aufruf. Parameter (alle steuern das aufrufende LLM; Sie schreiben diese normalerweise nie selbst):

Ergebnis: verdict, consensus (nur true bei einem nachgewiesenen APPROVED: sauberes JSON, null erforderliche Änderungen, kein Fallback-Parsing), critique, required_changes, suggestions, risks_identified, thread_id, Dauer und Token-Nutzung pro Runde und gesamter Überprüfung, reviewer_model / reviewer_reasoning_effort (bestmögliche Auflösung: Überschreibung, sonst codex-Konfiguration, sonst null), report_id / report_path (die strukturierte Berichtsdatei; report_error, wenn sie nicht geschrieben werden konnte – die Überprüfung selbst ist nicht betroffen) und eine next_action-Anweisung (Text + typisierte Felder), die die Schleife steuert.

clonst_feedback

Zeichnet eine Bemerkung darüber auf, wie Clonst funktioniert – zu anspruchsvoll, unklare Frage, falscher Umfang, zu langsam, Ausgabestil. Claude ruft es selbst auf, wann immer du so etwas sagst, egal ob du Clonst, Claude oder niemanden direkt ansprichst. Nur Metadaten: kein Reviewer-Aufruf, kein Kontingent, kein Netzwerk. Es zählt Vorkommen pro Thema und teilt Claude mit, wenn eines wiederkehrend wird; es ändert niemals selbstständig ein Verhalten.

clonst_topics

Listet, durchsucht oder benennt diese Themen um. Nur lokaler Dateizugriff – es startet nie etwas. action: "list" / "search" (mit query, limit, offset), um zu sehen, was sich angesammelt hat; action: "describe", um die einzeilige Beschreibung eines Themas zu verbessern.

clonst_report_summary

Fügt die Zusammenfassung in Klartext nach dem Konsens unverändert in die Überprüfungsberichtsdatei ein. Erwartet report_id (von clonst_review zurückgegeben – nicht thread_id) und summary. Nur Metadaten: kein Reviewer-Spawn, kein Kontingent, idempotent.

Konfiguration

Optionale Datei, standardmäßig nicht vorhanden: Erstelle selbst ~/.clonst/config.json, um einen beliebigen Schlüssel zu ändern. Sie wird bei jedem Aufruf neu gelesen; ungültige Werte fallen mit einer Warnung auf den Standardwert zurück.

Beispiel, das Überprüfungen ein eigenes Modell und eine schnellere Aufwandsstufe gibt, während deine Codex-Erweiterung ihre eigenen Einstellungen behält:

{
  "codex_model": "gpt-5.6-sol",
  "codex_reasoning_effort": "medium"
}

Verwende ein Modell, das deine codex-CLI tatsächlich bereitstellt (codex übernimmt es aus ~/.codex/config.toml, wenn du codex_model auf null lässt). Eine mittlere Aufwandsstufe ist für Überprüfungen normalerweise der richtige Kompromiss: Das Ping-Pong fängt das ein, was ein einziger tiefer Durchgang bringen würde, über etwas mehr Runden, und jede Runde kommt schneller zurück.

Überschreibungen werden als root--c-Flags an die codex-CLI übergeben (Vertrag verifiziert auf codex 0.142.5 für exec und resume); ein der codex unbekannter Wert schlägt die Überprüfung mit der eigenen Fehlermeldung von codex fehl.

Projekt-Review-Richtlinien: CLONST.md

Lege eine CLONST.md im Projektstamm ab, und wann immer eine Überprüfung mit project_path läuft, wird ihr Inhalt dem Reviewer als projektspezifische Richtlinien übergeben – deine Konventionen, deine roten Linien, zusätzlich zu den eigenen Standards des Reviewers geprüft. Beispiel:

# Review guidelines
- SQL must stay compatible with BOTH SQLite (dev) and PostgreSQL (prod).
- Every new route needs rate limiting.
- LLM results must be matched by ID, never by list position.

Geschäftsinvarianten gehören auch hierher – die roten Linien, die die Intent-Abweichungsprüfung verteidigen soll. Mache sie konkret und überprüfbar: Schreibe nicht „halte es einfach“, sondern schreibe „kostenlose Benutzer müssen CSV exportieren können“ oder „der Checkout muss ein Klick bleiben“.

Richtlinien können nur PRÜFUNGEN HINZUFÜGEN: Eine Richtlinie, die versucht, die Messlatte zu senken oder ein Urteil zu erzwingen, wird ignoriert und als Risiko gemeldet.

Intent-Abweichung und Benutzerentscheidungen

Die Überprüfung ist nicht nur technisch: Bevor die Codequalität geprüft wird, vergleicht der Reviewer das Ergebnis mit dem von dir angegebenen Intent (context, CLONST.md) oder dem, der aus dem Projekt ersichtlich ist. Es erfindet niemals deine Produktziele – wenn es eine mögliche Produktpräferenz statt eines nachgewiesenen Widerspruchs erkennt, gibt es ein Risiko aus, das mit dem wörtlichen Marker USER DECISION: beginnt. Jeder solche Punkt muss dich unverändert als offene Frage erreichen: Mitten in der Überprüfung pausiert es das Ping-Pong, bevor irgendetwas anderes passiert, und beim Konsens landet es im Abschlussbericht und in der Berichtsdatei. Claude darf es weder entscheiden, ausführen noch fallenlassen. Ein nachgewiesener stiller Wechsel des benutzersichtbaren Verhaltens kann die Überprüfung dagegen sofort blockieren.

Beide Seiten sind an derselben Kalibrierung gemessen: Blockiere bei materiellen Mängeln, gewichte Wahrscheinlichkeit und Kosten, und fordere niemals eine Funktion, die das Ergebnis nicht enthält. Vorausschau betrifft die Struktur, nicht die Funktionen – das heutige Design darf keine absehbare Tür verschließen, aber die zukünftige Funktion selbst wird jetzt nicht gebaut. Wenn der Reviewer unsicher ist, ob eine Richtung vorgesehen werden sollte, fragt er dich, anstatt zu entscheiden.

Die Prüfung ist symmetrisch. Claude wendet Kritiken nicht blind an: Jede Forderung wird auf sachliche Richtigkeit, Intent-Passung und Schlagkreis (was sonst noch von der Änderung abhängt) geprüft, bevor sie angewendet wird – und eine Forderung, die etwas anderes kaputtmachen würde, wird mit einer Begründung und einer sichereren Alternative abgelehnt, mit der sich der Reviewer auseinandersetzen muss, anstatt sich zu wiederholen. Beide Modelle argumentieren auf eine Lösung hin; Sackgassen gehen an dich.

Dein Feedback, gemerkt

Sag Claude, eine Überprüfung sei zu pingelig gewesen oder eine Frage unlesbar, und es zeichnet die Bemerkung über clonst_feedback in ~/.clonst/feedback.jsonl auf – du musst Clonst dafür nie direkt ansprechen. Jede Bemerkung wird einem Thema mit einer einzeiligen Beschreibung zugeordnet, und Claude verwendet ein vorhandenes Thema wieder, wenn deine neue Bemerkung dasselbe bedeutet, egal wie unterschiedlich du es formulierst. Sobald ein Thema feedback_recurring_threshold-mal zurückkommt, teilt Claude dir das mit.

Nichts wird jemals automatisch angewendet: Keine aufgezeichnete Bemerkung gelangt jemals in die Eingabeaufforderung des Reviewers. Das Tagebuch zu lesen und zu entscheiden, was verbessert werden soll, ist eine menschliche Entscheidung – frage „Was sagt mein Feedback?“ und Claude gruppiert gleichwertige Themen in seiner Antwort. Eine nur einmal gesehene Bemerkung wird nach feedback_retention_days gelöscht; alles, was zwei- oder mehrmals gesagt wurde, wird unbegrenzt aufbewahrt. Lösche die Datei, um alles zu entfernen.

Rundenlimits: unbegrenzt standardmäßig

Sag nichts, und das Ping-Pong läuft bis zum Konsens weiter, mit einem Check-in alle suggested_max_rounds Runden. Oder frage in natürlicher Sprache („überprüfe das, maximal 3 Runden“): Der Reviewer wird über den Zähler informiert (ausführlich ab Runde 1, maximale Anstrengung in der letzten Runde, niemals nur zum Abschluss genehmigen), und beim Limit geht die Uneinigkeit zur Schlichtung an dich.

Datenschutz und Kontingent

• Jede Überprüfungsrunde verbraucht dein ChatGPT-Abonnementkontingent (Codex führt die Überprüfung durch). Wenn das Kontingentfenster erschöpft ist, erkennt Clonst das und teilt Claude mit, ohne Überprüfung fortzufahren; die Sitzung bleibt später über dieselbe thread_id fortsetzbar.

• Mit project_path liest Codex das gesamte Projekt schreibgeschützt (einschließlich .env) und dieser Inhalt geht an OpenAI – die gleiche Offenlegung wie bei direkter Verwendung der Codex VS Code-Erweiterung. Standardstrategie: Nur den in content übergebenen Inhalt überprüfen; project_path für Überprüfungen reservieren, die echte APIs, Verträge oder Dateien verifizieren müssen.

• Überprüfungsinhalte verbleiben lokal außerhalb des Gesprächs: Sitzungsprotokolle und rohe Reviewer-Antworten unter ~/.clonst/logs/ und die menschenlesbaren Berichte (Kritiken und Änderungsdeklarationen unverändert) unter ~/.clonst/reports/. Lösche diese Verzeichnisse, um vergangene Überprüfungen zu entfernen.

• Aufgezeichnetes Feedback bleibt ebenfalls lokal: ~/.clonst/feedback.jsonl (unter macOS/Linux mit Nur-Besitzer-Berechtigungen erstellt) enthält deine Bemerkungen unverändert, sodass es trotz der No-Code-Regel sensible Formulierungen enthalten kann. Es wird niemals irgendwohin gesendet und niemals in eine Eingabeaufforderung eingefügt. Wenn du Claude bittest, es zu lesen, gelangen seine Inhalte in dieses Gespräch wie jede andere Datei, die du öffnen lässt – behandle sie als Daten, niemals als Anweisungen. Lösche die Datei, um sie zu entfernen.

• Ein Clonst-Serverinstanz pro Gespräch ist das Betriebsmodell; Berichtsschreibvorgänge werden prozessintern serialisiert. Richte nicht zwei gleichzeitig laufende Server auf dasselbe CLONST_HOME.

Fehlerbehebung

Jedes Ping-Pong wird vollständig unter ~/.clonst/logs/<thread_id>.jsonl protokolliert, mit vollständigen rohen Antworten in ~/.clonst/logs/raw/<thread_id>/.

Entwicklung

npm test          # build + hermetic test suite (no LLM calls)
npm run smoke     # full MCP protocol smoke test

Die Skripte scripts/probe-*.ps1 fixieren den tatsächlichen codex-CLI-Vertrag und verbrauchen ChatGPT-Kontingent: nur manuelle Ausführung. Das ReviewerProvider-Interface ist für andere Reviewer-CLIs (z. B. Gemini) vorbereitet.

Lizenz

MIT. Bereitgestellt wie besehen, ohne Supportgarantie. Täglich vom Autor verwendet.