ClaudeX Loop geprüft: warum ich es nicht installiere und welche Idee ich trotzdem übernommen habeClaudeX Loop reviewed: why I am not installing it and the one idea I kept

Ein 64-Sekunden-Reel verspricht, dass Fable 5.1 und GPT-6 Astra sich mit einem kostenlosen Skill gegenseitig kontrollieren. Der Skill heißt ClaudeX Loop und liegt offen auf GitHub. Ich habe das Repo heute gegen mein eigenes Setup gelesen. Installiert habe ich es nicht. Eine Idee daraus läuft seit heute Nachmittag trotzdem bei mir, und drei Codex-Runden haben sie vorher auseinandergenommen.

Dieser Beitrag ist der dritte Teil einer Reihe. „Claude Code einrichten“ baut das Grundsystem, „Claude Code baut. Codex prüft“ ergänzt Codex als unabhängigen Reviewer. Hier geht es um die Frage, wofür eine Codex-Freigabe eigentlich gilt. Du kannst den Text ohne die beiden anderen lesen.

was ClaudeX Loop macht

ClaudeX Loop ist ein Paket aus vier Skills von Chase AI, Version 2.1.0, MIT-Lizenz. Es läuft als Plugin in Claude Code oder als kopierte Skills in Codex. Früher hieß das Repo grill-me-codex und danach crucible. Die alten Interview-Skills von Matt Pocock liegen noch im Ordner legacy/.

Der Hauptskill claudex-loop teilt die Arbeit so auf, dass nie ein Modell seine eigene Arbeit abnimmt. Die laufende Sitzung sammelt Anforderungen und schreibt einen PLAN.md mit Prüfbefehlen. Der andere Anbieter liest Plan und Code und antwortet mit APPROVED, REVISE oder BLOCKED. Nach der Freigabe wird gebaut. Eine frische Sitzung des Anbieters, der nicht gebaut hat, inspiziert das Ergebnis.

Das Interessante steckt im Python-Runner, 420 Zeilen. Er zählt eine leere Antwort oder einen bloßen Sitzungsstart nie als Freigabe. Die Freigabe speichert Pfad und SHA256 des Plans, und eine Änderung am Plan macht sie ungültig. Die Inspektion speichert den Commit vor dem Build und einen Fingerprint der geprüften Änderungen, inklusive gestagter und neuer Dateien. Codex prüft in der read-only-Sandbox, Claude bekommt beim Prüfen nur Lese- und Suchwerkzeuge.

Daneben gibt es claudex-route. Der Skill empfiehlt, welches Modell eine Aufgabe übernimmt, und startet auf Wunsch genau eine Übergabe. Er läuft unabhängig vom Loop.

was das reel verkürzt

Im Reel heißt es, Fable 5.1 plane, Astra prüfe, danach tauschten beide die Rollen und Astra baue. Das README beschreibt es anders. Der Host, also das Werkzeug, in dem du startest, plant und baut standardmäßig selbst. Der andere Anbieter prüft Plan und Code. Wer Codex bauen lassen will, setzt builder=codex.

Auch die Modelle sind keine feste Paarung. Fable 5.1 und GPT-6 Astra nennt das README als mögliche Wahl, jede Kommandozeile behält sonst ihr eingestelltes Modell. Ein stiller Wechsel auf ein anderes Modell ist ausdrücklich ausgeschlossen.

die prüfung gegen mein setup

Mein Ablauf steht seit dem 23.09. und ist im Orchestrierungs-Beitrag beschrieben. Claude Code schreibt, Codex liest und meldet Befunde mit Beleg. Skills wie /request-codex-review und /ship-gate tragen die Schritte. Jeder Loop hat eine harte Grenze von drei Runden, danach entscheide ich.

Gegen dieses Setup gelesen, fallen fünf Punkte auf, die doppeln oder widersprechen. Einer fehlte bei mir.

Der schwerste Punkt ist das Schreibrecht. Mit builder=codex startet der Runner Codex mit sandbox_mode="workspace-write". In meinem Setup schreibt Codex nur mit einem ausdrücklichen, abgegrenzten Auftrag. Zwei Abläufe nebeneinander hätten genau die Frage aufgeworfen, die der Master-Loop beantworten soll: Wer entscheidet, wenn beide etwas anderes sagen.

Den Runner habe ich nach riskanten Mustern durchsucht, ohne Treffer. Er startet git und die beiden Kommandozeilen, unter Windows deren Node-Einstieg direkt, ohne shell=True und ohne eigene Netzwerkaufrufe. Das Paket ist sauber gebaut. Es passt nur nicht in einen Ablauf, der schon steht.

die idee, die ich übernommen habe

Mein Ship Gate prüfte bis heute, ob in .ai/codex/ ein ungelöstes Review liegt. Es prüfte nicht, ob das Review zum Code passt, der ausgeliefert wird. Genau dort lag eine Lücke, die mich am 23. und 24.09. schon einmal erwischt hatte. Drei Codex-Läufe fanden in den Fixes des jeweils vorigen Laufs neue kritische Fehler, und alle Tests waren grün.

ClaudeX Loop bindet die Freigabe an einen Hash. Das habe ich als kleines Skript nachgebaut. Es berechnet einen SHA256 über den gesamten Arbeitsbaum: getrackte Dateien, gestagt oder nicht, neue Dateien und die rohen Bytes jeder Datei. Ignorierte Dateien und der Ordner .ai/ zählen nicht mit. Ein Commit ändert den Wert nicht, jede Änderung am Inhalt oder am Ausführungsbit schon.

Der Ablauf hat drei Stellen. /request-codex-review schreibt den Fingerprint in den Review-Auftrag. /consume-codex-review speichert die Codex-Antwort als Datei und trägt Job-ID, Ergebnisdatei, geprüften Fingerprint und Status in den Auftrag ein. /ship-gate rechnet den Fingerprint neu und öffnet nur, wenn er gleich ist und der Status resolved lautet. Ein Fix nach dem Review ergibt einen neuen Wert, also braucht er ein neues Review.

drei Codex-runden gegen den eigenen fix

Ein Skript, das Reviews absichern soll, bekommt selbst eines. Ich habe es dreimal adversarial von Codex prüfen lassen, jedes Mal gegen den neuesten Stand.

In Runde 1 fand Codex sieben Befunde, drei davon kritisch. Der schönste: Der Review-Auftrag liegt in .ai/codex/, und das Schreiben des Auftrags änderte den Fingerprint, den er festhält. Ein Git-Submodul konnte sich nach dem Review ändern, ohne dass der Wert sich rührte. Beides war mit einem Wegwerf-Repo belegt.

Einen Befund habe ich in Runde 1 verworfen. Codex zeigte, dass ein Git-Clean-Filter geänderte Bytes vor dem Fingerprint versteckt. Mein Argument war, dass auch ein Diff-Review nur die gefilterte Sicht sieht. In Runde 2 kam derselbe Punkt mit einem Beleg zurück, der mein Argument aushebelte: Ein Deploy aus dem Arbeitsordner liefert die ungefilterten Bytes aus. Ich habe die Verwerfung zurückgenommen. Das Skript hasht seitdem zusätzlich die rohen Bytes.

Runde 3 war nach meiner eigenen Regel die letzte. Zwei Textkorrekturen am Ship Gate habe ich übernommen. Den Befund zu Dateinamen mit Zeilenumbruch habe ich verworfen. Das Skript bricht in dem Fall mit Exit 128 ab, das Gate bleibt zu, eine falsche Freigabe entsteht nicht.

wie ich prüfe, dass die prüfung prüft

Ein grüner Test ist erst ein Beleg, wenn er auch rot werden kann. Das Testskript baut Wegwerf-Repos und prüft jede Zusage einzeln. Nach einem Commit muss der Wert gleich bleiben. Ändert sich eine neue Datei mit Leerzeichen im Namen, muss er sich ändern. Ein geändertes Submodul muss zum Abbruch führen. Von Runde zu Runde kamen Kontrollen dazu.

Die Gegenprobe lief so: Ich habe jede Korrektur einzeln wieder aus einer Kopie des Skripts entfernt. In allen acht Fällen wurde genau die zugehörige Kontrolle rot. Zwei meiner eigenen Fehler hat erst dieser Durchgang gezeigt. Die Bash 3.2 auf macOS konnte das Skript nicht einlesen, und bei einem Fehler in der Mitte hätte es einen halben Hash ausgegeben.

Den achten Fall fand erst der echte Einsatz, beim Deploy genau dieses Beitrags. Im Repo der Website steht .ai in der .gitignore. Das Skript nannte den Ordner beim git add ausdrücklich als Ausnahme, und Git bricht ab, sobald ein Befehl einen ignorierten Pfad beim Namen nennt. Das Gate blieb zu, aber aus dem falschen Grund. Die Ausnahme war überflüssig, weil die nächste Zeile den Ordner ohnehin entfernt. Seitdem gibt es dafür die 28. Kontrolle.

so baust du es nach

Du brauchst weder ClaudeX Loop noch eine API. Das Skript nutzt git und shasum. Lege es in den Skill-Ordner, der deine Review-Aufträge schreibt, und rufe es immer mit bash auf.

#!/usr/bin/env bash
# Ein SHA256 über den Arbeitsbaum: getrackt (gestagt oder nicht) plus
# untracked, ohne ignorierte Dateien und ohne .ai/. Commit ändert ihn nicht,
# jede Byte-Änderung und jedes geänderte Ausführungsbit schon.
# Der echte Index bleibt unberührt.
set -euo pipefail
unset GIT_DIR GIT_WORK_TREE GIT_COMMON_DIR GIT_INDEX_FILE
cd "$(git rev-parse --show-toplevel)"
if git status --porcelain=v2 --ignore-submodules=none -- . ':(exclude).ai' | grep -qE '^[12] .. S(.[^.].|..[^.])'; then
  echo "dirty submodule: commit it first, fingerprint not possible" >&2
  exit 1
fi
idx=$(git rev-parse --git-path index)
tmp=$(mktemp)
trap 'rm -f "$tmp"' EXIT
if [ -f "$idx" ]; then cp "$idx" "$tmp"; else rm -f "$tmp"; fi
export GIT_INDEX_FILE="$tmp"
git -c core.filemode=true add -A -- .
git rm -r -q --cached --ignore-unmatch -- .ai >/dev/null
fp=$({
  git write-tree
  git ls-files -s -z | while IFS= read -r -d '' e; do
    case $e in (100644*|100755*)
      p=${e#*$'\t'}
      if [ -f "$p" ] && [ ! -L "$p" ]; then printf '%s\n' "$p"; fi ;;
    esac
  done | git hash-object --no-filters --stdin-paths
} | shasum -a 256 | cut -d' ' -f1)
echo "$fp"

Dann bekommt das Ship Gate einen Prüfpunkt, der Fingerprint, Status und Codex-Ergebnis zusammen verlangt. Ein Ergebnis, das nur eingefügt wurde und keine Job-ID hat, reicht dafür nicht.

3. No unresolved Codex review exists in .ai/codex/, and a review request
   there carries Reviewed-Fingerprint equal to the output of
   bash ~/.claude/skills/request-codex-review/scripts/review-fingerprint.sh
   run now, plus Review-Status: resolved, Codex-Job and Codex-Result.
   The file named in Codex-Result must exist and be non-empty, and
   /codex:result <Codex-Job> must show a completed job whose output
   matches that file and whose task names this request file or its
   fingerprint. A result pasted without a job id is not gate evidence.
   Mismatch = content changed after the review. Missing line or script
   error = BLOCKED, not PASS.

Zuletzt schreibt der Skill, der Codex-Befunde verarbeitet, die Bindung in den Auftrag.

8. Save Codex's verbatim output next to the request as
   <request-name>-result.md, then append to the review request file:
   Codex-Job: <job id>
   Codex-Result: <path of that file>
   Reviewed-Fingerprint: <the request's Fingerprint>
   Review-Status: resolved | open
   No Codex output = no status lines. If fixes changed code, they are
   unreviewed: write a new review request with a new fingerprint.

Teste das Skript in einem Wegwerf-Repo, bevor du dich darauf verlässt. Ändere eine Datei und prüfe, dass der Wert sich ändert. Committe ohne Änderung und prüfe, dass er gleich bleibt.

wann ClaudeX Loop trotzdem passt

Wer noch keinen eigenen Review-Ablauf hat, bekommt mit ClaudeX Loop einen durchdachten. Streng ist er an den Stellen, an denen Reviews sonst still kaputtgehen. Eine leere Antwort gilt nie als Freigabe, und jede spätere Änderung braucht eine neue Inspektion. Du brauchst beide Kommandozeilen mit Anmeldung und Python 3.10 oder neuer. Die Tests laufen laut README unter Windows, macOS und Linux.

Wer schon ein System hat, liest das Repo besser als Ideensammlung. Bei mir blieb eine Idee übrig, die gefehlt hat. Die Schleife selbst, also Planen, Prüfen, Bauen und erneut Prüfen, beschreibt der Beitrag „Die Agent-Schleife“ ausführlicher.

häufige fragen

Was ist ClaudeX Loop?

Ein kostenloses Skill-Paket unter MIT-Lizenz, das in Claude Code oder Codex läuft. Der Host schreibt den Plan, der andere Anbieter prüft ihn in bis zu fünf Runden. Danach baut standardmäßig der Host, und eine frische Sitzung des anderen Anbieters inspiziert den Code.

Baut bei ClaudeX Loop GPT-6 Astra und Fable 5.1 prüft?

Nur wenn du es so einstellst. Laut README baut standardmäßig der Host, also Claude in Claude Code. Mit builder=codex übernimmt Codex das Bauen. Geprüft wird immer vom Anbieter, der nicht gebaut hat.

Warum hast du ClaudeX Loop nicht installiert?

Mein Setup hat schon einen Ablauf von DEFINE bis SHIP, in dem nur Claude Code schreibt und Codex liest. ClaudeX Loop würde einen zweiten Ablauf danebenstellen, Codex Schreibrechte geben und mehr Runden erlauben als meine Grenze von drei. Die Grill-Skills und claudex-route decken sich mit Werkzeugen, die ich schon nutze.

Was ist ein Review-Fingerprint?

Ein SHA256 über den gesamten Arbeitsbaum, inklusive ungespeicherter und neuer Dateien. Er wird beim Review-Auftrag gespeichert und vor dem Release neu berechnet. Weicht er ab, hat sich der Code nach dem Review geändert und das Ship Gate bleibt zu.

Ändert ein Commit den Fingerprint?

Nein. Der Fingerprint hängt am Inhalt, nicht am Commit. Jede Änderung an Bytes oder am Ausführungsbit einer Datei ändert ihn dagegen, auch eine, die Git-Filter vor git diff verstecken würden.

Brauche ich dafür ClaudeX Loop oder eine API?

Nein. Das Skript nutzt nur git und shasum. Es passt in jeden Ablauf, der Codex-Reviews als Dateien festhält.

quellen und stand

Stand: 24.09.2026. Alle Zahlen zu Befunden, Kontrollen und Laufzeiten stammen aus meinen eigenen Läufen an diesem Tag. Die Messung mit 20.000 Dateien hat Codex in Runde 3 durchgeführt. Angaben zu ClaudeX Loop beziehen sich auf Version 2.1.0.

• Chase AI: ClaudeX Loop auf GitHub (README, runtime.md, runner.py)
• Anthropic: Skills
• Git: git-write-tree
• Git: git-hash-object