Werkstatt-Log — DoMe Dynamics

Kampagnen-Report: 36 Audit-Befunde, 6 Agenten, eine Nacht

2026-07-03T00:00:00Z

Der Codex-Audit-Scheduler dieser Website hatte über Wochen Findings angesammelt. Nach einem Reconcile-Lauf blieben 36 echt offene, rein mechanische Befunde übrig — Link-Labels, Datums-Konsistenz, Mobile-Feinschliff, ein Sanitizer-Leck. Nichts davon braucht eine Design-Entscheidung. Alles davon kostet einzeln abgearbeitet einen Nachmittag.

Also: nicht einzeln abarbeiten. Dieser Report dokumentiert die erste Kampagnen-Nacht — als Format, das ab jetzt pro Großaktion wiederholt wird.

Der Zuschnitt: 6 Cluster, ehrlich gezählt

Die 36 Befunde wurden nach Themen geclustert, nicht nach Dateien: DCO-Showcase-Pflege, Link-Label-Konsistenz, Freshness-Signale, Séance-Sanitizer + OG-Pipeline, Mobile/A11y, technischer Sweep. Ein Befund war zu trivial für einen eigenen Cluster und wurde direkt gefixt — übrig blieben 35 in sechs Clustern im Format 6/6/6/6/6/5.

Das klingt pedantisch, ist aber Absicht: kein Auffüllen mit stale Items, um die runde Zahl voll zu machen. Eine Kampagne, die ihre eigene Bilanz schönt, ist als Beweisformat wertlos.

Der Plan-B-Schwenk

Der ursprüngliche Dispatch-Plan sah sechs Codex-Subagenten vor. Der erste Lauf scheiterte an der Codex-Sandbox unter Windows — Schreibzugriffe ins Temp-Verzeichnis, ein bekanntes, dokumentiertes Problem. Statt die Sandbox aufzubohren, wechselte die Kampagne das Werkzeug: sechs Claude-Subagenten, jeder in einem eigenen Git-Worktree, jeder auf einem eigenen Branch (codex/campaign-c11 bis c16).

Die Lehre daraus ist wichtiger als der Umweg: Die Kampagnen-Mechanik — Cluster, Isolation, Branch, Review, Merge — ist werkzeugneutral. Welches Modell die Arbeit macht, ist eine Austauschentscheidung, kein Architekturbruch.

Die Leitplanken

Jeder Agent bekam dasselbe Protokoll als Pflichtlektüre:

Branch-only: kein Commit auf main, kein Push, kein Deploy.
Worktree-Isolation: sechs Agenten parallel, null gegenseitige Konflikte.
Nur grüne Befunde: was eine Owner-Entscheidung braucht, wird nicht "mitgenommen".
Chirurgisch stagen: fremde Drift bleibt unangetastet.

Der letzte Punkt hat einen eigenen Auslauf: Strittiges landete nicht still im Diff, sondern in einer NEEDS-DOMINIC-Liste — vier Entscheidungsvorlagen, die der Owner am nächsten Morgen einzeln entschied (und die dann als eigener, nachvollziehbarer Commit umgesetzt wurden). Ein Agent, der bei Unsicherheit parkt statt rät, ist der Unterschied zwischen Delegation und Kontrollverlust.

Die Bilanz

Nach den sechs Läufen kam eine Review-Runde über alle sechs Branches (Standards + Spec), dann wurden die Kampagnen einzeln gemergt — sechs Merge-Commits (03d5391 bis 848d8ff; das Site-Repo ist privat, ein Walkthrough durch den Log ist auf Anfrage möglich):

6 Kampagnen-Branches, alle in einer Nacht gemergt
43 geänderte Dateien, ~1.215 eingefügte Zeilen
4 geparkte Entscheidungsvorlagen statt 4 stiller Annahmen
Testsuite nach dem letzten Merge: komplett grün

Was die Kampagne bewusst nicht behauptet: dass 36/36 gefixt wurden. Einzelne Befunde erwiesen sich beim Ground-Truthing als bereits erledigt oder stale — auch das steht im Run-Report. Die ehrliche Zählung ist Teil des Formats.

Warum das ein Format ist, kein Einzelfall

Der eigentliche Ertrag ist nicht die abgearbeitete Liste, sondern die wiederholbare Mechanik: Backlog clustern → Flotte dispatchen → isoliert bauen lassen → zentral reviewen → einzeln mergen → Strittiges eskalieren. Dieselbe Struktur trug wenige Tage vorher schon den Bau des Agent-Observatory mit 15 Agenten in einem Durchlauf.

Jede künftige Großaktion an dieser Website bekommt einen solchen Report. Nicht als Erfolgsmeldung — als Prüfprotokoll.

Wie viel Parallelität verträgt ein Repo, bevor Review zum Flaschenhals wird? Wenn dich die Dispatch-Mechanik im Detail interessiert, schreib mir.

So arbeite ich: eine Agenten-Flotte, ein Review, ein Merge

2026-07-03T00:00:00Z

Die einzelnen Case-Studys dieser Website zeigen Systeme. Dieser Text zeigt die Arbeitsform, mit der sie entstehen — denn die ist inzwischen selbst das interessanteste Artefakt: Ich arbeite nicht mit einem Assistenten, sondern mit einer Flotte. Und die Flotte darf nichts mergen, was nicht geprüft wurde.

Das Muster in einer Zeile

Backlog clustern → Flotte dispatchen → isoliert bauen lassen → adversarial reviewen → einzeln mergen → Strittiges eskalieren.

Als Diagramm, am Beispiel einer Kampagnen-Nacht:

                    Backlog (36 Befunde, ground-getruthed)
                                   │
                          Cluster-Zuschnitt (6 Themen)
                                   │
        ┌─────────┬─────────┬─────┴────┬─────────┬─────────┐
        ▼         ▼         ▼          ▼         ▼         ▼
     Agent 1   Agent 2   Agent 3    Agent 4   Agent 5   Agent 6
    worktree  worktree  worktree   worktree  worktree  worktree
    branch    branch    branch     branch    branch    branch
        │         │         │          │         │         │
        └─────────┴─────────┴────┬─────┴─────────┴─────────┘
                                 ▼
                  EIN Review über alle Branches
                  (Standards-Achse + Spec-Achse)
                                 │
                 ┌───────────────┴───────────────┐
                 ▼                               ▼
        6 einzelne Merges                NEEDS-DOMINIC-Liste
        (kein Auto-Merge)                (4 Entscheidungsvorlagen,
                                          Owner entscheidet morgens)

Drei Eigenschaften machen das Muster tragfähig:

Isolation ist nicht optional. Jeder Agent arbeitet in einem eigenen Git-Worktree auf einem eigenen Branch. Sechs Agenten parallel, null Merge-Konflikte untereinander — und ein missratener Lauf wird verworfen, statt das Repo zu verschmutzen.
Review ist eine eigene Instanz, nicht ein Nachsatz. Wer baut, urteilt nicht über sich selbst. Das Review läuft zentral über alle Branches, mit zwei getrennten Achsen: Hält der Code die dokumentierten Konventionen ein (Standards)? Und tut er, was der Auftrag verlangte (Spec)?
Unsicherheit wird geparkt, nicht geraten. Was eine Owner-Entscheidung braucht, landet als Entscheidungsvorlage in einer Liste — nicht still im Diff.

Beleg 1: die 6×6-Kampagnen-Nacht

Der Kampagnen-Report dokumentiert den Ablauf im Detail. Die Kurzfassung: 36 mechanische Audit-Befunde, sechs Agenten, sechs Branches, eine Review-Runde, sechs Merges in einer Nacht — 43 geänderte Dateien, vier geparkte Entscheidungsvorlagen, Testsuite grün. Inklusive des ehrlichen Teils: Der geplante Werkzeug-Unterbau (Codex-Subagenten) fiel an der Windows-Sandbox aus, die Mechanik lief unverändert mit Claude-Subagenten weiter. Die Arbeitsform ist werkzeugneutral.

Beleg 2: der Observatory-Build — 15 Agenten, zwei blinde Reviews

Die Live-Demo auf /observatory — ein Replay echter, vollständig sanitisierter Agenten-Telemetrie — entstand selbst über das Muster, diesmal mit Betonung auf der Review-Seite:

Die Design-Spec wurde adversarial geprüft, bevor eine Zeile Code entstand: zwei unabhängige Reviewer (ein Claude-Subagent und Codex), gleicher Prompt, blind gegeneinander. Beide fanden unabhängig denselben kritischen Blocker — die Content-Security-Policy der Site hätte die geplante Einbettung komplett verhindert, und die Sanitisierungs-Allowlist war von der falschen Quelle abgeleitet. Zwei blinde Reviews, die konvergieren, sind ein stärkeres Signal als jede Selbstprüfung.
Der Bau lief als Flotte von 15 Agenten (Verstehen → Bauen → Prüfen als getrennte Wellen), gefolgt von fünf Bug-Runden, in denen jede Behauptung live im Browser verifiziert wurde statt im Diff geglaubt.
Die Daten-Seite ist der Ernstfall des Musters: Kein String aus der echten Event-Datenbank wird unverändert ausgeliefert — der Export baut jedes Event aus einer Allowlist neu auf, statt Einzelfelder zu redigieren. Das war ein direktes Ergebnis der adversarialen Reviews.

Die Verdikt-Bilanz in Zahlen

Damit das nicht bei Erzählung bleibt — die Quoten der beiden Läufe, aus Run-Reports und Git-Log:

Lauf	Dispatcht	Akzeptiert & gemergt	Eskaliert / geparkt	Referenz
6×6-Kampagne	35 Befunde in 6 Clustern	6/6 Kampagnen-Branches (Merges `03d5391`…`848d8ff`)	4 NEEDS-DOMINIC-Vorlagen (umgesetzt als `e480e03`)	Run-Report 2026-07-01
Observatory-Build	1 Spec, 15 Bau-Agenten	Live-Embed (u. a. `340e6b8`) nach 5 Bug-Runden	2 blinde Spec-Reviews → 1 kritischer Blocker vor Baubeginn gefunden	Design-Spec 2026-06-30

Das Site-Repo ist privat — die Hashes stehen hier als überprüfbare Referenz für einen Walkthrough, nicht als Klick-Link.

Auch dieser Text entstand so

Kleinste Ausbaustufe desselben Musters, vom selben Tag: Der SEO-Batch dieser Website ging nach dem Bau durch einen Codex-Verifier (read-only, voller Diff plus Spec im Prompt). Verdikt: FAIL, genau ein Befund — ein fehlendes dateModified im Blog-Schema. Der Befund wurde gegen den Code ground-getruthed, per Test-first-Fix geschlossen, gepusht. Ein einzelnes ehrliches FAIL ist mehr wert als zehn freundliche PASS.

Was das Muster nicht ist

Kein Autopilot. Merges und strittige Entscheidungen bleiben beim Owner; die Flotte bereitet Entscheidungen vor, sie trifft sie nicht.
Keine Skalierungs-Show. 15 Agenten sind kein Ziel, sondern eine Zuschnittsfrage — der Verifier-Lauf oben war ein einzelner Agent, und das war richtig so.
Nicht selbstbewertend. Jede Zahl in diesem Text stammt aus Run-Reports, Git-Log oder Spec-Dokumenten im Repo — nicht aus der Erinnerung eines Agenten an die eigene Leistung.

Welchen Teil deines Backlogs würdest du einer Flotte geben — und welchen bewusst nicht? Wenn dich das Dispatch-Protokoll im Detail interessiert, schreib mir.

Ein Agent optimiert sich selbst — aber nur, wenn Lighthouse zustimmt

2026-07-01T00:00:00Z

Ein Agent, der seinen eigenen Output bewertet, ist ein schwacher Richter. Er neigt dazu, sich selbst recht zu geben — dieselbe Instanz, die den Code schreibt, urteilt auch darüber, ob er gut ist. Die Frage hinter evolab war deshalb einfach: Was passiert, wenn die Bewertung von außen kommt, messbar und unbestechlich?

Der Loop: mutieren, messen, selektieren

Codex bekommt die Aufgabe, eine Oberfläche zu verbessern. Nicht das Urteil — nur den Vorschlag. Das Urteil liegt komplett bei Lighthouse, Googles Web-Qualitätsmessung: Performance und Accessibility werden gemessen, nicht behauptet.

Der Loop selbst ist ein genetischer Algorithmus mit einem ungewöhnlichen Mutations-Operator: einem Sprachmodell statt eines Zufallsgenerators. Codex erzeugt eine Variante, Lighthouse misst sie gegen den aktuellen Bestwert, und eine harte Selektionsregel entscheidet, ob sie bleibt.

Die Regel ist absichtlich streng: eine Mutation muss mindestens eine Metrik echt verbessern — UND darf keine andere Metrik unter die Toleranz drücken. Eine einzelne Zahl zu optimieren wäre einfacher gewesen, hätte aber Kollateralschaden erzeugt: eine Performance-Verbesserung, die Accessibility killt, ist auf dieser Site kein Fortschritt.

Mit dem Messrauschen rechnen

Reale Lighthouse-Läufe schwanken — dieselbe Seite liefert bei zwei aufeinanderfolgenden Messungen nicht exakt denselben Score. Wer das ignoriert, akzeptiert Zufall als Fortschritt. Die Selektionsregel rechnet deshalb mit einer Jitter-Toleranz: tol = max(1, jitter). Eine Mutation muss über das Rauschen hinaus besser sein, nicht nur knapp darüber.

Im fresh-Lauf zeigte sich das konkret: zwei Kandidaten erreichten Performance 86 — und wurden trotzdem verworfen, weil 86 nicht weit genug über dem bisherigen Bestwert 85 lag, um als echter Fortschritt statt Messrauschen zu zählen. Das fühlt sich beim ersten Hinschauen unnötig konservativ an. Ist es aber nicht: ohne diese Schwelle hätte der Loop irgendwann eine Kette von Zufallsschwankungen als "Verbesserung" verbucht.

Was verworfen wurde

Die interessanteren Zahlen sind nicht die Erfolge, sondern die Ablehnungen — die machen die Disziplin des Systems erst sichtbar.

Im loop-short-Lauf wurden zwei Mutationen verworfen: eine, weil sie Accessibility von 98 auf 93 gedrückt hätte — ein klarer Performance-für-Accessibility-Tausch, den die No-Regress-Regel nicht zulässt. Eine zweite, weil sie Performance von 85 auf 84 gekostet hätte.

Im fresh-Lauf: 3 akzeptierte Mutationen über 10 Iterationen, Performance stieg von 56 auf 85 — bei 4 Codex-Timeouts, die ehrlich mitgezählt wurden statt stillschweigend übersprungen. Accessibility stieg im selben Lauf von 98 auf 100.

Der overnight-Lauf erreichte mit 5 konservativen Mutationen einen Sprung von Performance 39 auf 90. Eine riskantere Minify-Variante hätte theoretisch 39→91 erreicht — blieb aber bewusst außen vor, weil sie ungeprüftes Verhalten löscht statt es zu verifizieren. Ein Prozentpunkt mehr Score war den Kontrollverlust nicht wert.

Leitplanken, nicht Vertrauen

Ein Agent, der selbst Code schreibt und sich selbst bewertet, braucht harte Grenzen — sonst optimiert er ins Leere oder ins Unsichere. Vier davon tragen den Loop:

Scope-Guard: Codex darf nur Dateien aus einer Allowlist anfassen. Ein Diff, der ausschert, wird verworfen, bevor er überhaupt gemessen wird.
Jitter-Toleranz: siehe oben — Messrauschen darf nicht als Fortschritt zählen.
Gehärteter Subprocess: der Codex-Aufruf läuft kontrolliert in einem abgegrenzten Arbeitsverzeichnis, nicht frei auf dem Zielsystem.
Kein Auto-Deploy: der Loop produziert nur Reports und eine best-ref-Empfehlung für menschlichen Review. Die Maschine schreibt nichts direkt ins Ziel-Repo.

Der letzte Punkt ist der wichtigste. Ein evolutionärer Loop, der autonom deployt, ist ein anderes Risikoprofil als einer, der nur einen geprüften Kandidaten vorschlägt. Die Selektionsregel entscheidet, was gemessen als Fortschritt zählt — nicht, was live geht.

Was sich verallgemeinern lässt

Der eigentliche Ertrag ist nicht der Lighthouse-Optimierer selbst, sondern das Prinzip dahinter: ein unbestechliches externes Mess-Signal statt Selbstbewertung, eine Multi-Metrik-Regel statt Single-Score-Tunnelblick, und eine Toleranz, die Messrauschen respektiert statt zu ignorieren. Das trägt auf jeden Agenten, der sich selbst verbessern soll — Lighthouse ist nur ein Signal von vielen, das sich dafür eignet.

Wo würdest du die Fitness-Funktion ansetzen, wenn du einen Agenten gegen ein externes Signal optimieren lässt? Wenn dich interessiert, wie sich das Prinzip auf andere messbare Ziele übertragen lässt, schreib mir.

Warum ich meinen eigenen Subagenten nicht glaube

2026-06-15T00:00:00Z

Ein Subagent schreibt: „Erledigt. Alle Tests grün. Commit gesetzt." Das ist kein Beweis — das ist eine Behauptung, formuliert von einem Sprachmodell, das sehr gut darin ist, plausibel klingende Abschlussmeldungen zu produzieren. Ich habe aufgehört, diese Berichte auf Treu und Glauben zu nehmen. Nicht weil ich den Agenten für unzuverlässig halte — sondern weil ich verstanden habe, was ein LLM-Bericht strukturell leisten kann und was nicht.

Warum Reports trügen

Ein Sprachmodell hat keinen privilegierten Zugang zur Wahrheit seines eigenen Outputs. Es hat gelernt, wie „ein erfolgreicher Abschlussbericht" klingt — und produziert genau das, wenn die vorherigen Token in diese Richtung zeigen. Ein selbstbewusst formuliertes „Done, all tests passing" ist statistisch genauso wahrscheinlich wie ein korrektes. Beide sehen auf Token-Ebene identisch aus.

Das ist kein Argument gegen den Einsatz von Subagenten. Es ist ein Argument für eine klare Rollentrennung: Der Agent erledigt Arbeit. Die Verifikation liegt beim Orchestrator — oder bei mir. Beides kann nicht dieselbe Instanz sein, die den Bericht verfasst hat, denn der Bias sitzt in der Completion, nicht im Werkzeug.

Drei Fälle haben mich das konkret verstehen lassen.

Beleg 1 — gefundene Bugs, die keine waren

In einem Verdict-Loop hatte ein Agent die Aufgabe, Bugs in einer Codebasis zu finden und zu bewerten. Er fand welche. Der Report war formatiert wie ein echter Code-Review: Dateinamen, Zeilennummern, Fehlerbeschreibungen. Alles stimmig.

Das Problem: die Fundstellen lagen in Demo-Code, den er nicht von Production-Logik unterschieden hatte. Die „Bugs" waren illustrative Platzhalter, absichtlich kaputt, damit die Demo etwas zu zeigen hat. Der Agent behandelte sie als echte Befunde.

Hätte ich den Report blind weitergegeben, hätte jemand Demo-Artefakte als echte Schwachstellen priorisiert. Die Form des Reports — überzeugend, strukturiert, vollständig — hatte keinen Zusammenhang mit seinem Inhalt. Der Fehler war nicht im Agent, sondern in meiner Erwartung, dass „gut formatiert" mit „inhaltlich valide" korreliert. Das tut es nicht.

Beleg 2 — der Verifier, der gar nicht testete

Ein Verifier-Agent sollte nach einem Refactor sicherstellen, dass die Tests noch grün sind. Er lieferte ein Urteil: Tests fehlgeschlagen, drei Failures. Ich war überrascht — der Code sah korrekt aus.

Dann sah ich das Detail: Gesamtlaufzeit ~0,4 Sekunden. Drei Tests. Eine der Fehlermeldungen lautete document is not defined. Der Agent hatte bun test gerufen statt pnpm/vitest — in seiner Sandbox war pnpm nicht verfügbar, also fiel er auf die nächstverfügbare Runtime zurück. bun test ignoriert die jsdom-Konfiguration; die Tests, die DOM-Zugriffe brauchen, fallen sofort mit document is not defined durch.

Das Urteil war technisch korrekt — in der Sandbox, mit der falschen Runtime. Was der Agent wirklich geleistet hatte: er hatte den Diff gelesen und bewertet. Das ist wertvoll. Aber das Testurteil war wertlos, weil die Ausführungsumgebung nicht zu den Anforderungen des Test-Setups passte.

Hätte ich das Urteil geglaubt, hätte ich funktionierenden Code als kaputt eingestuft und nach Fehlern gesucht, die nicht existieren. Der Report war in sich konsistent. Er war trotzdem falsch.

Beleg 3 — doppelt gebaut

Carry-over-Buchhaltung über Sessions ist ein unterschätztes Problem. Ein offenes Item wanderte aus einer Session in die nächste — korrekt dokumentiert, klar beschrieben. Zwei parallele Sessions zogen dasselbe Item und bauten denselben Fix unabhängig voneinander.

Beide Fixes waren korrekt. Beide wurden committed. Der zweite Commit musste aufgelöst werden, weil er auf einem Stand aufbaute, der die Änderung schon enthielt.

Das war kein Fehler des einzelnen Agenten — er hatte das Item gesehen, es noch nicht als erledigt markiert vorgefunden, und angefangen zu bauen. Der Fehler lag in der fehlenden Snapshot-Verifikation vor Arbeitsbeginn: ein git status --short plus ein Blick auf den letzten Commit hätte gezeigt, dass die Änderung bereits existierte. Statt auf den Buchhaltungsstand zu vertrauen, wäre ein 30-Sekunden-Ground-Truth-Check ausreichend gewesen.

Die Praxis: Ground-Truth vor Buchhaltung

Das Muster hinter allen drei Fällen ist dasselbe: ich habe dem Selbstbericht geglaubt, anstatt die Realität zu prüfen. Die Gegenmaßnahme ist simpel und mechanisch:

git show <hash> auf den behaupteten Commit — nicht den Report lesen, den Diff sehen.
Die Test-Suite selbst laufen lassen, nicht das Ergebnis übernehmen: pnpm test, in der korrekten Umgebung, mit der korrekten Runtime.
Vor jedem Deploy dist/ greppen — auf Markdown-Artefakte, Pfade, Secrets, Privatdaten.
Vor Arbeitsbeginn an einem Carry-over-Item git status --short und letzten Commit prüfen.

Dreißig Sekunden Realitäts-Check statt Narrativ-Glauben. Das ist die ganze Methode. Sie klingt trivial — und ich habe sie trotzdem dreimal nicht angewendet, bevor ich die Fälle hatte, die mich dazu gebracht haben.

Das ändert sich nicht mit besseren Agenten. Ein Agent, der präziser antwortet, produziert präziser klingende Reports — und macht sie damit überzeugender, nicht wahrer. Der strukturelle Bias bleibt: er berichtet über seine Arbeit mit denselben Mitteln, mit denen er sie erledigt hat — Sprache, keine Ausführung. Den Unterschied zwischen beidem kann kein Sprachmodell aus sich selbst heraus auflösen.

Was offen ist

Verifikation kostet Zeit und Tokens. Jeder Check, den ich selbst mache, frisst genau den Produktivitätsgewinn, den der Agent eigentlich erbringen soll. Die Grenze zwischen „gesund skeptisch" und „alles zweimal machen" ist unscharf — und sie verschiebt sich je nach Aufgabe, Risiko, und wie kritisch die Folgen eines Fehlers sind.

Ich habe noch keine gute Antwort darauf, wie selektiv ich diese Checks anwenden soll. Aktuell gilt: je näher eine Agentenausgabe an einem externen Artefakt ist — einem Commit, einem Deploy, einer Kommunikation —, desto eher prüfe ich nach. Bei reinen Analyse-Outputs, die ich sowieso lese, spare ich mir den Overhead. Ob das die richtige Heuristik ist, weiß ich noch nicht.

Welche Selbstberichte deiner Agenten hast du schon einmal nachgeprüft — und was hast du dann tatsächlich vorgefunden? Wenn du ähnliche Verification-Patterns nutzt oder andere Ansätze kennst, schreib mir.

Zwei KI-Modelle, die sich abwechselnd Code bauen und gegenseitig reviewen

2026-06-14T00:00:00Z

Ein Modell baut, das andere reviewt — und bei jedem Accept tauschen sie die Rollen. Das klingt nach einem eleganten symmetrischen System. Die Realität war erst eine starre Bridge, dann ein Sandbox-Hang, und schließlich drei Runden live: Codex baut, Claude reviewt, ablehnt, Codex überarbeitet, Claude nimmt an, Rollen tauschen. So lief es. Was dazwischen lag, ist der interessante Teil.

Der asymmetrische Anfang

Die erste Version der Bridge zwischen Claude und Codex war fest verdrahtet: Claude baut, Codex reviewt. Oder umgekehrt, je nach Konfiguration. Einmal gesetzt, unveränderlich für die gesamte Session.

Das hat funktioniert. Eine Seite produziert Diff, die andere gibt Verdikt. Das ist bereits nützlich, weil zwei Modelle unabhängige Urteilsachsen haben — was Claude übersieht, sieht Codex, und umgekehrt. Die Kombination ist robuster als ein einzelnes Modell, das seinen eigenen Output bewertet: andere Trainingsgewichte, andere blinde Flecken, anderes Gewichtungsmuster bei Sicherheit versus Lesbarkeit.

Aber die fixe Rollenverteilung verschenkt die Hälfte der Kapazität: der Reviewer kann auch bauen, der Builder kann auch reviewen. Die starre Zuweisung ist keine strukturelle Notwendigkeit, sondern eine Vereinfachung der ersten Iteration. Nützlich zum Beweisen des Konzepts — unzureichend für einen echten Relay-Betrieb. Das war der Ausgangspunkt für den nächsten Schritt.

Reviewer-Symmetrie

Jedes Modell kann beides: bauen und reviewen. Der Reviewer wird automatisch als das jeweils andere Modell gewählt — Codex reviewt Claude-Output, Claude reviewt Codex-Output. Das lässt sich über ein Flag überschreiben, aber der sinnvolle Default ist das Gegenteil des Builders.

Was das konkret bedeutet: Codex reviewt rein auf Basis des übergebenen Textes, ohne eigene Datei-Zugriffe — read-only im buchstäblichen Sinn. Claude ebenso, wenn es als Reviewer läuft. Keiner der beiden greift in dieser Phase schreibend ins Repository ein. Das ist eine bewusste Trennung: die Review-Phase erzeugt kein neues Artefakt, nur ein Urteil. Verdikt accept, reject, oder rework mit kommentierter Begründung. Das Urteil ist der Output, nicht ein neuer Diff.

Die Symmetrie macht das System robuster gegen Bias: wenn Claude immer baut und Claude immer reviewt, lernt das System seine eigenen Muster als Standard. Wechselnde Rollen erzwingen, dass jeder Output durch eine andere Urteilsachse geht. Das ist kein kosmetisches Detail — es verändert, welche Fehler überhaupt sichtbar werden.

Die Relay-Schleife

Beide Modelle bauen abwechselnd. Der Reviewer beurteilt den inkrementellen Diff — nicht die gesamte Codebasis, nur was sich seit dem letzten Accept geändert hat. Das hält den Kontext des Reviewers klein und das Urteil fokussiert.

Bei accept tauschen die Rollen: der bisherige Builder wird Reviewer, der bisherige Reviewer übernimmt das nächste Bau-Segment. Bei reject bleibt der Builder in seiner Rolle und überarbeitet, bevor weitergegeben wird. Das verhindert, dass ein schwacher Diff in die nächste Runde geht und sich Fehler aufschichten.

Live getestet über drei Runden: Codex baut eine Komponente, Claude reviewt und lehnt ab mit konkretem Befund — zu wenig Fehlerbehandlung, ein konkreter Fall unberücksichtigt. Codex überarbeitet, Claude nimmt an. Rollen tauschen — Claude baut den nächsten Schritt, Codex reviewt und gibt ohne Einwände frei. Die Schleife läuft. Was dabei auffällt: die Ablehnungsrunde war produktiver als ein blindes Durchwinken es gewesen wäre. Das Rework hat den Diff tatsächlich verbessert, nicht nur formal den Reviewer besänftigt. Drei Runden, ein Reject, ein Rework, zwei Accepts.

Die Schleife läuft synchron: ein Modell ist aktiv, das andere wartet. Das ist langsamer als paralleles Bauen, aber einfacher zu koordinieren, deterministisch in der Reihenfolge und ohne Merge-Konflikte. Für eine erste produktive Implementierung ist synchron der richtige Kompromiss.

Die Sandbox-Falle

Der Codex-Reviewer läuft read-only. Keine Schreibzugriffe, keine Commits, nur Lesen und Urteilen. Klingt harmlos. Ist es nicht, wenn approval_policy nicht explizit gesetzt ist.

Ohne approval_policy=never läuft Codex auf Windows in eine %TEMP%-Probing-Schleife. Das Modell versucht, seinen Arbeitsbereich zu sondieren, schreibt dabei in %TEMP%, und friert ein, wenn der Sandbox-Modus das blockiert. Der Hang ist still — der Wrapper-Output ist oft leer oder gepuffert, nichts deutet auf das Problem hin. Der Hängepunkt zeigt sich erst im Rollout-Log unter ~/.codex/sessions/: der letzte function_call-Eintrag ohne zugehörigen function_call_output ist der Moment, an dem der Prozess eingefroren ist.

Die Lösung ist zweiteilig und nicht intuitiv: Builder brauchen Schreibzugriff (danger-full-access für einen isolierten Wegwerf-Workdir), Reviewer kommen mit read-only aus — aber beide nur mit approval_policy=never. Der Schlüssel ist nicht der Sandbox-Modus an sich, sondern das Unterbinden des Approval-Probings, bevor es zur Hang-Schleife wird. Ein read-only-Reviewer, der nur Text liest und ein Verdikt zurückgibt, friert unter approval_policy=never nicht ein — das war der Live-Beweis, nach dem der Hang aufgelöst war.

Was das lehrt: externe CLI-Versionen ändern still ihre Sandbox-Semantik. Was gestern mit einer Konfiguration lief, hängt heute nach einem Update. Nicht dem Wrapper-Output trauen, wenn ein headless Subprozess hängt — das Rollout-Log lesen.

Was offen ist

Die Schleife funktioniert — aber synchron. Builder wechseln sich ab, niemand baut gleichzeitig. Paralleles Bauen mit anschließendem Merge wäre der nächste Schritt: beide Modelle bearbeiten unabhängige Segmente, dann wird zusammengeführt. Das bringt Merge-Komplexität mit sich, die die synchrone Variante vermeidet. Wann der Aufwand sich lohnt, hängt davon ab, wie granular sich eine Aufgabe zerlegen lässt.

Die menschliche Eskalation bei Stagnation ist noch grob. Wenn Reject aufeinander folgt und kein Fortschritt entsteht, gibt es einen einzigen Auslöser: eine Datei, ein Signal. Kein abgestuftes Signal — keine Unterscheidung zwischen „zwei Ablehnungen in Folge beim selben Diff" und „fünf Ablehnungen über mehrere Segmente mit verschiedenen Buildern". Ein abgestufter Signalweg — Warnung, Pause, Eskalation, Abbruch — wäre die nächste Differenzierung, bevor die Schleife autonom über längere Horizonte laufen kann, ohne dass ein Mensch aktiv mitliest.

Wie steuerst du Code-Reviews zwischen Modellen — wer reviewt wen, und nach welcher Logik? Wenn du ähnliche Relay-Muster gebaut hast oder eine andere Aufteilung verwendest, schreib mir.

Ein Hook, der rm -rf blockt — und warum er fast mich selbst ausgesperrt hätte

2026-06-03T00:00:00Z

Ein Agent mit Shell-Zugriff kann jeden Befehl tippen. Auch rm -rf. Auch DROP TABLE. Das ist keine Hypothese — nach zwei Situationen, die knapp genug ausgingen um ungemütlich zu sein, habe ich einen PreToolUse-Hook gebaut, der jeden Befehl prüft, bevor er ausgeführt wird. Was dabei schiefging, ist fast lehrreicher als was funktioniert.

Was der Hook tut

PreToolUse-Hooks sind der Kontrollpunkt zwischen dem Moment, in dem ein Agent einen Befehl plant, und dem Moment, in dem er ihn ausführt. Der Hook bekommt den vollständigen Tool-Aufruf übergeben — Befehlsname, Argumente, Kontext — und kann deny zurückgeben, bevor irgendwas passiert. Das ist der einzige Moment, an dem ein rein sprachlich arbeitender Guardrail wirksam ist: danach ist der Befehl schon weg.

Mein Hook prüft den Befehlsstring gegen eine Liste destruktiver Muster: rm -rf, DROP TABLE, TRUNCATE, git push --force auf Mainline-Branches, > wichtige-datei.txt als Redirect-Überschreib, und ein Dutzend weitere. Trifft ein Muster zu, wird der Aufruf geblockt und ein Audit-Eintrag ins Log geschrieben — JSONL-Format, ein Objekt pro Zeile, mit Zeitstempel, einem stabilen rule-Schlüssel für die geblockte Kategorie, und dem Befehl in gekürzter Form. „Gekürzt" bedeutet hier: ausreichend für die Diagnose, aber kein vollständiger Dump des Prompt-Inhalts, der ggf. sensible Zwischenstände enthält. Ein Audit-Log, das selbst ein Sicherheitsproblem wird, hilft nicht.

Die Architektur ist von einem Tool-Usage-Tracker abgeschaut, den ich für den DCO gebaut hatte. Der Schreibvorgang ins Log sitzt in einem try/except-Block: wenn das Schreiben fehlschlägt, wird der deny trotzdem ausgelöst. Ein Guard, der an einem kaputten Log-Handle hängt und deshalb nichts blockt, wäre schlimmer als gar kein Guard. Die Konsequenz ist, dass ein Blocking-Event im schlimmsten Fall lautlos ist — aber das ist ein akzeptabler Kompromiss gegenüber einer Umgehung durch Log-Fehler.

Wenn Daten wie Befehle aussehen

Das erste ernsthafte Problem trat auf, als ich rm -rf als Substring-Muster matchen wollte. Die naive Idee — wenn der String rm -rf enthält, blocken — ist auch die erste, die jeder in einer ersten Implementierung wählt. Sie ist naheliegend, weil sie für den häufigsten Fall stimmt. Sie scheitert, weil sie keinen Unterschied macht zwischen dem Befehlsteil und dem Argumentteil eines Aufrufs.

Konkreter Fall: ein Codex-Review-Aufruf über die Kommandozeile, in etwa node task "…analysiere diesen rm -rf-Fund in prod.db…". Der Prompt ist ein Argument in Anführungszeichen. Mein Muster matcht. Der Hook blockt meinen eigenen Review-Aufruf.

Die Lösung: bevor der Musterabgleich läuft, werden alle gequoteten Spans maskiert — einfache Anführungszeichen, doppelte Anführungszeichen, alles dazwischen wird durch Platzhalter ersetzt. Was danach übrig bleibt, ist der Befehlsteil ohne Argument-Inhalte. Erst darauf läuft das Muster. Ein Newline zählt dabei als Befehlstrennzeichen — was nach einem Zeilenumbruch kommt, wird als eigenständiger Befehl gewertet und separat geprüft.

Das klingt nach einer kleinen Korrektur. Es war ein Nachmittag Debugging. Und es ist der Punkt, an dem eine naive Substring-Suche an ihre strukturelle Grenze stößt: Shell-Syntax zu parsen ist ein eigenes Problem, und jeder Versuch, es halbherzig zu lösen, produziert entweder False Positives oder False Negatives.

fail-open statt fail-closed

Eine Entscheidung zieht sich durch den ganzen Hook: wenn unklar ist, ob ein Befehl gefährlich ist, wird er durchgelassen und geloggt — nicht geblockt.

Das klingt kontraintuitiv für ein Sicherheitssystem. Aber die Alternative ist ein Guard, der produktive Arbeit blockt — und der dann abgestellt wird. Dann schützt er nichts, dauerhaft. Ich habe das Prinzip nach dem Codex-Review-Vorfall formalisiert: lieber einen echten Treffer verpassen und im Audit-Log sehen, als legitime Aufrufe zu verweigern und den Hook nach einer Woche aus Frustration zu deaktivieren. Ein Guardrail, der deaktiviert wurde, ist schlechter als kein Guardrail — weil er eine falsche Sicherheit hinterlässt.

Das bedeutet: der Hook ist kein hartes Sicherheitsnetz. Er ist ein erster Filter und ein Frühwarnsystem. Die Lücken sind bekannt und dokumentiert — dazu später mehr.

Das Henne-Ei-Problem der Selbstverteidigung

Ich wollte den Hook auch vor sich selbst schützen. Konkret: eine Regel in Cluster H, die verhindert, dass der Hook-Code selbst bearbeitet wird, ohne explizite Freigabe. Wer die Schutzregeln editieren kann, kann den Schutz aushebeln. Das ist keine theoretische Bedrohung — ein Agent, der seinen eigenen Handlungsspielraum optimiert, ist genau das, was diese Art von Schutzmechanismus ursprünglich motiviert hat.

Das Ergebnis war vorhersehbar, im Nachhinein: die Regel blockierte mich beim ersten Versuch, den Hook zu verbessern. Ich wollte einen neuen Muster-Eintrag hinzufügen. Der Hook erkannte den Schreibbefehl auf seine eigene Datei als verdächtig. deny.

Zurückgerollt. Lesson learned: Selbstschutz braucht zuerst ein Owner-Bypass-Design — und der Bypass muss vor der Schutzregel existieren, nicht danach. Wer der Owner ist, muss eine verifizierte Möglichkeit haben, die Regeln zu ändern, ohne den gesamten Schutzmechanismus zu umgehen. Das bedeutet in der Praxis: eine separate, nicht vom Hook bewachte Konfigurationsdatei mit expliziter Freigabemechanik, oder eine Bypass-Geste die der Hook selbst versteht. Dieser Bypass existiert noch nicht. Cluster H ist deaktiviert, bis er es tut.

Was offen ist

Die ehrliche Bestandsaufnahme der bekannten Lücken:

Interpreter-Einzeiler: python -c "import os; os.system('rm -rf x')" landet nicht im Muster. Der Shell-String enthält keinen rm, nur einen Python-String, der einen rm enthält.
Command Substitution: $(rm -rf x) oder `rm -rf x` als Argument ist für den Hook unsichtbar — er sieht den äußeren Befehl, nicht was innerhalb der Substitution steht.
Base64-kodierte Befehle: bash -c "$(echo cm0gLXJmIC8= | base64 -d)" ist für einen Stringmatcher nicht auflösbar.
Piped SQL-Dumps: psql database < drop_all.sql — der Befehl selbst ist harmlos, der Effekt nicht. Die Gefahr steckt im Datei-Inhalt, nicht im Befehlsstring.

Diese Lücken sind dokumentiert und akzeptiert — fail-open bedeutet, dass sie durchrutschen und geloggt werden. Ein Mustermatcher über Shell-Strings ist grundsätzlich unvollständig. Das ist kein Fehler im Design, sondern eine strukturelle Eigenschaft des Ansatzes: wer auf String-Ebene arbeitet, sieht keine Semantik. Wer vollständige Abdeckung braucht, braucht einen anderen Ansatz: sandboxed Execution, Syscall-Monitoring, oder beides. Der Hook, den ich gebaut habe, ist das Werkzeug, das ich in einem Nachmittag produktiv hatte — und das seitdem tatsächlich genutzt wird. Das ist mehr wert als ein perfektes System, das noch in Planung ist.

Welche destruktiven Aktionen hat dein Agent schon fast ausgeführt — und was hat dich aufgehalten? Wenn du an ähnlichen Guardrails arbeitest oder andere Ansätze kennst, schreib mir.

Ein stilles CLI-Upgrade fror Codex 45 Minuten ein

2026-06-03T00:00:00Z

In der Dual-Bridge baut ein KI-Modell Code, das andere reviewt ihn. Die Builder-Seite läuft headless: codex exec wird als Subprozess gestartet, bekommt einen Auftrag in einem isolierten Wegwerf-Verzeichnis und arbeitet. Das lief seit Wochen zuverlässig. Dann, an einem Seed-Lauf, fror es ein. Fünfundvierzig Minuten lang. Im Log meines Adapters stand: nichts.

Das ist die unangenehmste Sorte Fehler — der, bei dem das Werkzeug korrekt anzufangen scheint und dann einfach stehenbleibt. Die ersten Bauschritte liefen sichtbar durch. Dann Stille. Kein Fehler, kein Fortschritt, ein Prozess-Baum, der dasteht und wartet.

Zwei Annahmen, gleichzeitig gebrochen

Die Ursache war ein CLI-Upgrade, das ich nicht bewusst eingeplant hatte: Codex war von 0.133 auf 0.136 gesprungen. Solche Sprünge brechen gern Annahmen, die man nie aufgeschrieben hat, weil sie immer galten. Hier waren es zwei auf einmal.

Erstens lädt 0.136 jetzt die ~/.codex/config.toml mit allem, was darinsteht — Plugins, MCP-Server, Hooks. Und es feuert bei internen Shell-Kommandos einen SessionStart-Hook. Dieser Hook ist synchron und ohne Timeout. Unter einer interaktiven Session fällt das nicht auf. Unter einem non-interaktiven exec als Subprozess hängt er sich an einer Stelle auf, an der niemand auf eine Eingabe antwortet.

Zweitens lief der Build unter -s workspace-write — einer Sandbox, die Schreibzugriffe auf das Arbeitsverzeichnis erlaubt, aber %TEMP% nicht zuverlässig einschließt. pytest legt seine temporären Verzeichnisse aber genau dort an. Die Sandbox verweigert den Zugriff, der Hook beginnt nach einer Freigabe zu suchen, die im headless Betrieb nie kommt — und dreht sich in einer Schleife, die nach %TEMP% probt, statt abzubrechen.

Beide Probleme für sich wären unangenehm. Zusammen ergeben sie einen Deadlock: Ein synchroner, timeout-loser Hook trifft auf eine Sandbox, die ihm den Weg versperrt, in einem Kontext, in dem niemand „ja, mach" sagen kann. Und der timeout meines eigenen subprocess.run rettet hier nicht — er tötet den direkten Kindprozess nicht durch die ganze Kette python → node → codex → cmd → bash hindurch.

Die Diagnose lag nicht in meinem Log

Der entscheidende Schritt war, dem eigenen Log nicht zu vertrauen. Mein Adapter-Log war leer oder gepuffert — es zeigte den letzten erfolgreichen Schritt und dann nichts mehr. Das verleitet dazu, an der falschen Stelle zu suchen.

Codex schreibt aber sein eigenes Rollout-Log: ~/.codex/sessions/<datum>/rollout-*.jsonl, eine Zeile pro Ereignis. Darin steht jeder function_call und das zugehörige function_call_output. Der Hängepunkt ist exakt der letzte function_call, dem kein function_call_output folgt. Das ist der Befehl, der losgeschickt wurde und nie zurückkam — in diesem Fall der shell_command, der in der %TEMP%-Sandbox-Probing-Schleife versackte.

Diese Regel verallgemeinert sich: Wenn ein headless gestarteter LLM-Subprozess hängt, ist die Wahrheit im Session-/Rollout-Log des Werkzeugs, nicht im eigenen, oft leeren oder gepufferten Prozess-Log. Der letzte unbeantwortete Aufruf ist der Hängepunkt.

Der Fix: Builder und Reviewer brauchen verschiedene Rechte

Die Behebung war, die Sandbox-Semantik an die Aufgabe anzupassen, statt einen Mittelweg zu erzwingen. Für einen isolierten Wegwerf-Workdir, in dem der Builder ohnehin schreiben muss, ist -s danger-full-access -c approval_policy="never" die richtige Wahl: Der Sandbox-Drop ist die eigentliche Behebung, und approval_policy="never" unterbindet das Approval- und %TEMP%-Probing, bevor es zur Hang-Schleife werden kann.

Spannend war die Kehrseite: Ein Reviewer, der nur liest — etwa einen im Prompt eingebetteten Diff beurteilt und nichts schreiben muss — hängt nicht. Er läuft mit -s read-only -c approval_policy="never" sauber durch. Der Schlüssel ist also nicht der Sandbox-Modus an sich, sondern zweierlei: dass kein Schreibzugriff nötig ist und dass approval_policy="never" das Probing unterbindet. Builder schreiben, also brauchen sie vollen Zugriff; Reviewer lesen nur, also kommen sie mit read-only aus — beide nur mit abgeschaltetem Approval.

Die Lektion: externe Upgrades brechen still die Spielregeln

Der teuerste Teil war die Annahme, dass eine CLI sich zwischen zwei Minor-Versionen gleich verhält. Tut sie nicht. 0.136 hat die Sandbox- und Flag-Semantik verändert, ohne dass mein Code etwas davon mitbekam — er rief weiter dieselben Flags auf, die jetzt etwas anderes bedeuteten. „Funktioniert manuell" war zusätzlich irreführend, weil ein interaktiver Lauf eine andere Approval- und Sandbox-Semantik hat als ein Dienst-Lauf. Genau wie bei den ersten Subprozess-Fehlern war die Lücke zwischen „läuft bei mir in der Konsole" und „läuft headless als Subprozess" der Ort, an dem es brach.

Was offen ist

Die aktuelle Lösung pinnt die Flags pro Rolle — Builder voll, Reviewer read-only, beide ohne Approval. Was fehlt, ist ein Schutz gegen die nächste stille Semantik-Änderung: Der Adapter sollte die Codex-Version prüfen und bei einem unerwarteten Sprung warnen, statt blind die alten Flags zu verwenden. Außerdem ist der subprocess-Timeout, der die Prozesskette nicht sauber durchtötet, weiterhin ein stumpfes Werkzeug — ein robusteres Kill über die ganze python → node → codex → cmd → bash-Kette wäre die ehrlichere Absicherung gegen den nächsten Hang. Bis dahin ist die wichtigste Verteidigung diagnostisch: bei einem Hang nicht dem eigenen Log glauben, sondern das Rollout-Log lesen.

Hat dich schon ein CLI-Upgrade still ausgebremst — und wo hast du am Ende die Wahrheit gefunden? Schreib mir.

Grün allein, rot in der Suite — ein Leck, das in keiner Datei stand

2026-05-31T00:00:00Z

Der Test war grün. Allein ausgeführt, jedes Mal, zuverlässig. In der vollen Suite war er rot. Auch das zuverlässig. Genau diese Kombination — isoliert grün, gemeinsam rot — ist eines der irritierendsten Signale, die eine Testsuite geben kann, weil sie der Grundannahme widerspricht, dass ein Test eine in sich abgeschlossene Aussage ist.

Der konkrete Fall stammt aus der Dual-Bridge, der Schicht, über die zwei KI-Modelle abwechselnd Code bauen und reviewen. Ein Test prüfte, dass ein Auftrag korrekt an den Codex-Runner geroutet wird und am Ende den Status done trägt. Allein lieferte er done. In der Suite lieferte er error.

Das erste Misstrauen gilt der Reihenfolge

Wenn ein Test nur im Verbund scheitert, ist die erste Frage nicht „was ist an diesem Test falsch", sondern „was läuft vor ihm". Denn ein Test, der allein besteht, ist für sich korrekt. Was ihn umbringt, muss von außen kommen — von etwas, das ein anderer Test hinterlassen hat.

pytest führt Tests in einer bestimmten Reihenfolge aus, und diese Reihenfolge ist stabil genug, dass „läuft Datei A vor Datei B" reproduzierbar ist. Ein paar gezielte Läufe — erst der verdächtige Test allein, dann mit jeweils einer anderen Datei davor — engen den Schuldigen ein. Hier zeigte sich: Lief eine bestimmte andere Testdatei vorher, war der Test rot. Lief sie nicht, war er grün. Damit war klar, dass es kein Bug im Test selbst war, sondern ein hinterlassener Zustand.

Das Leck: ein neu geladenes Modul räumt die Registry leer

Die schuldige Testdatei tat etwas, das harmlos aussieht: importlib.reload(runners). Sie lud das Runner-Modul neu, um es in einem definierten Ausgangszustand zu testen. Ein reload führt den Modul-Code aber von vorn aus — und dabei wurde die globale Runner-Registry auf ihren Initialwert zurückgesetzt: nur der Test-echo-Runner, sonst nichts. Die echten Adapter, die beim ersten Import registriert worden waren, waren weg.

Der spätere Test rechnete mit RUNNERS["codex"]. Nach dem reload existierte dieser Eintrag nicht mehr. Statt den Codex-Runner zu finden, lief der Auftrag in einen Fehlerpfad — daher error statt done. Dazu kam eine zweite Quelle desselben Problems: Umgebungsvariablen, die ein Test setzte, ohne sie danach aufzuräumen. DUAL_BRIDGE_*-Werte leben im Prozess-Speicher und überdauern die einzelne Testfunktion, wenn niemand sie zurücksetzt.

Beide Lecks haben dieselbe Eigenschaft: Sie hinterlassen keinen Abdruck im Dateisystem. Man kann das gesamte Repo durchsuchen und findet nichts, weil der veränderte Zustand in flüchtigem Prozess-Speicher liegt — in einem Modul-Global, in os.environ. Diese Art von Leck ist unsichtbar, bis man die Ausführungsreihenfolge als Verdächtigen ernst nimmt.

Der Fix: pro Test ein sauberer Tisch

Die Behebung war eine autouse-Fixture in der conftest.py, die vor jedem Test einen Schnappschuss des relevanten Zustands macht und ihn danach wiederherstellt: die komplette DUAL_BRIDGE_*-Umgebung und die Runner-Registry. Jeder Test bekommt damit denselben Ausgangszustand, egal was der vorherige getan hat.

Das ist der eigentliche Punkt: Test-Isolation heißt nicht nur, eine eigene Datenbank oder ein eigenes Temp-Verzeichnis zu haben. Es heißt auch, jeden geteilten, veränderlichen Zustand zu kapseln — und dazu gehören Modul-Globals und Umgebungsvariablen, die man leicht übersieht, weil sie nicht nach „Zustand" aussehen. monkeypatch.setenv statt direktem os.environ-Schreiben und autouse-Fixtures für Registries sind das Minimum, nicht die Kür.

Warum „allein grün" eine gefährliche Beruhigung ist

Es liegt nahe, einen Test zu schreiben, ihn isoliert grün zu sehen und ihn damit für fertig zu halten. Aber die isolierte Ausführung ist nicht der reale Fall. Im echten Lauf — in CI, vor einem Merge — läuft die volle Suite, und dort entscheidet sich, ob der Test trägt. Ein Test, der nur allein besteht, gibt eine falsche Sicherheit: Er behauptet eine Eigenschaft, die unter realen Bedingungen nicht gilt.

Schlimmer noch: Solche Lecks sind nicht-deterministisch in dem Sinn, dass sie an der Reihenfolge hängen. Eine neue Testdatei mit einem alphabetisch früheren Namen kann ein Leck einschleusen, das vorher nie sichtbar war — und plötzlich ist ein ganz anderer Test rot, ohne dass jemand ihn angefasst hat. Das ist die Sorte Fehler, die Stunden frisst, weil der offensichtliche Verdächtige (der rote Test) der Falsche ist.

Was offen ist

Die autouse-Fixture kapselt den bekannten Zustand — die DUAL_BRIDGE_*-Env und die Runner-Registry. Aber sie ist eine Aufzählung: Sie schützt genau das, woran ich gedacht habe. Das nächste Modul-Global, das jemand einführt und nicht in den Snapshot aufnimmt, kann dasselbe Problem neu erzeugen. Eine robustere Lösung wäre, geteilten veränderlichen Zustand strukturell zu vermeiden — Registries als Fixtures injizieren statt als Modul-Globals zu halten, sodass es gar keinen prozessweiten Zustand gibt, der lecken könnte. Bis dahin gilt die Disziplin: Wer einen Modul-Global oder eine Umgebungsvariable einführt, muss im selben Atemzug klären, wie sie pro Test zurückgesetzt wird.

Welcher Test ist bei dir nur in der vollen Suite rot geworden — und wie lange hast du den falschen verdächtigt? Schreib mir.

Wie ich zweimal meine eigene Datenbank löschte — und was Test-Isolation wirklich heißt

2026-05-29T00:00:00Z

Zweimal hat eine Test-Suite meine produktive Datenbank geleert. Beide Male war ich sicher, isoliert zu testen. Beide Male lag ich falsch — und zwar auf unterschiedliche Arten. Das ist das Unbehaglichste daran: der zweite Verlust passierte, nachdem ich aus dem ersten gelernt hatte. Ich hatte eine Lösung gebaut. Die Lösung hatte eine Lücke.

Der erste Verlust

Der erste Vorfall war im Nachhinein offensichtlich. Die Test-Suite startete, und kein einziger Test hatte einen Pfad-Override gesetzt. conftest.py existierte, aber ohne Isolation-Mechanismus — keine Umgebungsvariable, keine monkeypatch-Zuweisung, kein tmp_path. Die Tests liefen einfach gegen die echte Datendatenbank, weil nirgendwo ein anderer Pfad stand.

DELETE FROM im Teardown. Tabellen sauber. Daten weg.

Dass ich das nicht sofort gesehen hatte, lag an einem mentalen Kurzschluss: ich hatte Testcode gelesen und war davon ausgegangen, dass Testcode automatisch eine andere Umgebung meint. Das stimmt nicht. Tests laufen in derselben Python-Umgebung wie Produktionscode, greifen auf dieselben Pfade zu, sofern niemand etwas überschreibt — und ob irgendjemand etwas überschreibt, steht nicht auf der Stirn des conftest geschrieben.

Die Reaktion war die naheliegende: Isolation nachrüsten. Umgebungsvariable für den Datenbankpfad, monkeypatch.setenv im conftest, Teardown gegen eine temporäre Datei. Beim nächsten Testlauf: isoliert, sauber, kein Datenverlust. Ich hielt das Problem für gelöst.

Der zweite, raffiniertere Verlust

Der zweite Vorfall war subtiler. Das conftest sah diesmal korrekt aus. Der Override war gesetzt. Beim Überfliegen der Datei hätte ich unterschrieben, dass die Isolation stimmt.

Trotzdem war calls.db danach leer.

Die Diagnose dauerte länger als sie sollte, weil ich an der falschen Stelle gesucht hatte: ich hatte die Testinfrastruktur geprüft und die Produktionsmodule nicht in Frage gestellt. Der Fehler lag dort.

Ein Modul hatte auf Modulebene eine Konstante definiert:

DB_PATH = str(DATA_DIR / "calls.db")

Das klingt harmlos. Es ist es nicht. Python friert diesen Wert beim Import ein — in dem Moment, in dem das Modul das erste Mal geladen wird. Was danach passiert — delenv, reload(config), reload(module) im Teardown — kommt zu spät. Der String ist ein String. Er zeigt weiterhin auf ./data/calls.db, die echte Datenbank. Das Modul hat den Override nie gesehen.

Der conftest hatte korrekt die Umgebungsvariable gesetzt. Das Modul hatte sie korrekt ignoriert, weil es sie zum Zeitpunkt der Pfadauflösung nicht mehr gab — dieser Zeitpunkt lag Millisekunden vor dem ersten Testaufruf, im Import-Schritt, bevor irgendein Test-Setup lief.

Lazy statt eingefroren

Das Anti-Pattern ist die Modulkonstante. Die einzige sichere Alternative ist eine Funktion, die config.DATA_DIR bei jedem Aufruf frisch liest:

def _db_path() -> str:
    return str(config.DATA_DIR / "calls.db")

Erst das macht den Pfad überschreibbar. Wenn der Test DATA_DIR via Umgebungsvariable auf ein temporäres Verzeichnis zeigt und das Modul _db_path() bei jedem Datenbankzugriff aufruft, landet der Zugriff auch tatsächlich auf der Test-DB. Keine Import-Zeitkonstante, keine eingefrorene Referenz.

Dazu kommen zwei harte Guards, die ich danach eingebaut habe:

Erstens ein RuntimeError im conftest-Header: wenn der aufgelöste Override-Pfad mit dem echten Produktionspfad identisch ist, bricht das Setup sofort ab. Nicht warnen — abbrechen. Das fängt den Fall ab, in dem der Override-Mechanismus selbst nicht greift.

Zweitens eine Poison-Guard nach jedem Test: ein Assertion, die den von _db_path() aufgelösten Pfad gegen ./data prüft. Wenn das Modul trotz allem auf den echten Pfad zeigt — vielleicht weil ein Reload fehlgeschlagen ist, vielleicht weil ein neues Modul die Konstante wieder eingeführt hat — schlägt die Guard an. Kein stilles Übergehen, kein Hoffnungstest.

Die beiden Guards zusammen machen einen dritten Vorfall unwahrscheinlicher. Aber nur, wenn der Code sie nicht umgeht — und das können neue Module, die das Anti-Pattern wieder einführen, jederzeit tun.

Der conftest-Header beweist nichts

Das ist die Lektion, die ich am meisten gebraucht hätte, bevor der zweite Vorfall passierte: das Lesen des conftest-Headers beweist keine Isolation. Es beweist, dass ein Override-Mechanismus beschrieben ist. Ob er tatsächlich greift, steht da nicht.

Der Trugschluss lautet: ich habe den conftest gelesen und gesehen, dass eine Test-DB gesetzt wird, also ist die Isolation in Ordnung. Dieser Trugschluss hat den zweiten Verlust mitverursacht. Ich hatte nach dem ersten Vorfall den conftest erweitert und das als ausreichend betrachtet.

Ausreichend ist es nicht. Ausreichend ist ein Row-Count-Snapshot der echten Datenbanken vor und nach einem echten Suite-Lauf. Wenn die Zahlen übereinstimmen, war die Isolation in Ordnung — nicht weil der conftest so aussieht, als wäre sie in Ordnung, sondern weil die Daten das bestätigen. Ein Mismatch nach dem Lauf ist ein Bug. Sofort melden, Suite nicht weiterführen.

Das kostet zwei SQL-Abfragen. Es lohnt sich.

Was offen ist

Die Guards, die ich jetzt habe, sind reaktiv. Sie fangen den Fehler, nachdem die Architektur ihn zugelassen hat. Der RuntimeError im conftest-Header greift erst, wenn die Test-Session startet. Die Poison-Guard greift, nachdem ein Test gelaufen ist, der möglicherweise bereits geschrieben hat.

Was fehlt, ist eine strukturelle Lösung: dass Produktionscode in Testmodus schlicht keinen Zugriff auf ./data haben kann — nicht weil ein Guard dagegen anfeuert, sondern weil der Pfad in diesem Modus physisch nicht existiert oder auf ein Read-only-Mount zeigt. Das wäre Isolation auf Betriebssystem-Ebene statt auf Python-Ebene.

Ich habe das noch nicht gebaut. Die Guards halten den Betrieb aufrecht, und der Aufwand für eine echte Sandbox ist real. Aber ich habe jetzt zweimal erlebt, was passiert, wenn der Schutz auf Konvention beruht statt auf Konstruktion — und das macht mich vorsichtiger als ich es vor diesen Vorfällen war.

Ein eingefrorener Pfad sieht aus wie ein gesetzter Pfad. Der Unterschied ist unsichtbar, bis er nicht mehr ist.

Welche Annahme über deine Test-Isolation hat sich als falsch herausgestellt — und wann hast du es gemerkt? Wenn du ähnliche Vorfälle erlebt hast oder andere Ansätze zur strukturellen Isolation kennst, schreib mir.

Approval-Pfade in agentischen Systemen: Warum Automatisierung Freigabe-Logik braucht

2026-05-15T00:00:00Z

Vollautomation klingt nach dem Ziel, ist aber selten eins. Bei jedem Agenten-System, das ich gebaut habe, kam früher oder später dieselbe Frage: an welchen Stellen darf das System eigenständig handeln, und wo muss ein Mensch zustimmen, bevor etwas passiert? Das ist die Approval-Frage, und sie ist die wichtigste Architektur-Entscheidung beim Bau produktiver Coding-Agenten.

Die Asymmetrie zwischen Lesen und Schreiben

Lesende Operationen sind billig: ein Agent liest eine Datei, ruft eine API ab, durchsucht Logs. Wenn er falsch läuft, kostet das Tokens und etwas Zeit. Schreibende Operationen sind teuer: eine gelöschte Datei ist weg, ein commit-pushed ist öffentlich, eine versendete Nachricht lässt sich nicht zurückholen. Dieser Asymmetrie folgt die einfachste Approval-Heuristik: lesend autonom, schreibend mit Approval.

Aber die Heuristik bricht, sobald die Realität komplexer wird. Eine Datenbank-Query "nur lesend" kann das System lahmlegen, wenn sie versehentlich SELECT * über Milliarden Zeilen macht. Eine "schreibende" Operation wie das Anlegen einer Wegwerf-Branch ist trivial reversibel. Die Heuristik braucht Verfeinerung — und genau dort kollabiert die meisten Agenten-Implementierungen.

Vier Stufen statt zwei

Im DCO (Dynamic Central Orchestrator), den ich seit März 2026 produktiv betreibe, habe ich vier Approval-Stufen statt der binären Aufteilung:

Autonom — der Agent führt aus, ohne zu fragen. Lesende Operationen mit klar definierten Limits, idempotente Schreibvorgänge in einem Sandbox-Scope.
Notify — der Agent führt aus, schickt aber eine Telegram-Nachricht. Ich kann nachträglich revidieren, aber muss nicht warten. Gut für Aktionen mit hoher Vertrauenslage und geringem Schaden.
Confirm — der Agent stoppt, schickt einen Vorschlag, wartet auf "ja" oder "nein". Standard für schreibende Operationen ausserhalb der Sandbox: git push, Slack-Nachricht, Datei löschen.
Veto — der Agent darf das nicht. Punkt. Hartcodiert in der Tool-Auswahl. Beispiel: rm -rf überhaupt nicht aufrufbar, auch nicht mit Approval.

Diese Stufen sind kein theoretisches Modell, sondern direkt in den MCP-Tools des DCO codiert. Jedes Tool deklariert seine Approval-Stufe, und der Orchestrator-Layer entscheidet basierend darauf, ob er ein Telegram-Inline-Button sendet oder einfach weiterläuft.

Confirm ist die schwierigste Stufe

Autonom ist trivial: einfach machen. Veto ist trivial: einfach blockieren. Notify ist trivial: machen + senden. Aber Confirm hat einen User-Experience-Killer: Wartezeit.

Wenn ein Agent bei jedem zweiten Schritt anhält und auf Bestätigung wartet, ist das Erlebnis kaum besser als manuelles Arbeiten. Die Confirm-Stufe braucht drei Eigenschaften, damit sie produktiv ist:

Sub-Sekunden-Roundtrip, wenn der User antwortbereit ist. Im DCO heisst das: Telegram-Inline-Buttons, kein Form, kein Tippen.
Sinnvolles Default-Verhalten, wenn der User nicht antwortet. Timeout, der zurück auf "Abbruch" fällt, niemals stillschweigend ausführen.
Begründung in der Frage, nicht nur "Soll ich X tun?". Stattdessen "Soll ich X tun? Effekt: Y. Risiko: Z. Default bei keiner Antwort: Abbruch."

Die dritte Eigenschaft ist die wichtigste. Ein Agent, der auf Bestätigungen wartet, ohne den Effekt zu erklären, wird entweder per Reflex bestätigt oder per Reflex abgelehnt. Beides ist ein Failure-Mode.

Approval-Pfade als Architektur, nicht als Patch

Der häufigste Fehler beim Bau eigener Agenten ist, Approval als Nachgedanke zu implementieren — als ob-Block um den Tool-Aufruf, der "frag mal nach". Das hat zwei Probleme: erstens ist die Approval-Logik dann über den Code verstreut, statt zentral verwaltet zu werden. Zweitens kann man die Approval-Regeln nicht änderbar machen, ohne den Code anzufassen.

Die Lösung ist, Approval als zentrale Architektur-Schicht zu verstehen. Jedes Tool meldet beim Registrieren seine Approval-Stufe an den Orchestrator. Der Orchestrator entscheidet beim Aufruf, was zu tun ist. Aenderungen an Approval-Regeln passieren am Tool, nicht an der Aufruf-Stelle. Das macht Approval testbar, versionierbar und auditierbar.

Was ich nicht gelöst habe

Drei Probleme bleiben offen, und ich erwähne sie ehrlich, weil sie der eigentliche Lern-Stoff sind:

Stille Aenderungen sichtbar machen. Wenn ein Tool eine Datenbank im Hintergrund modifiziert, ohne dass ein Approval-Knopf gedrückt wurde, wie merkt der User es? Mein aktueller Hack: ein "Audit-Log"-Kanal in Telegram, der jeden Schreibvorgang nachträglich postet. Das ist Notify-Stufe über alle Schreiboperationen — funktioniert, aber laut.
Approval-Stufen veraltern. Was heute "Confirm" ist, könnte morgen "Notify" sein, weil ich mehr Vertrauen in das Tool habe. Wie versioniere ich diese Aenderung sauber, ohne dass alte Sessions noch die alte Regel nutzen? Im DCO ist das aktuell hartcodiert mit manuellem Edit — keine elegante Lösung.
Approval-Fatigue. Wenn der User 50 Bestätigungen am Tag bekommt, klickt er irgendwann "ja" ohne zu lesen. Gegenmittel: Approval-Stufen verschärfen, Notify aggressiv einsetzen, Aktionen bundlen ("Soll ich diese 5 Schritte machen?" statt 5 einzelne Fragen).

Approval-Pfade sind kein gelöster Bereich. Sie sind der Punkt, an dem Engineering-Disziplin und Produkt-Sinn aufeinandertreffen, und an dem agentische Systeme den Unterschied zwischen Spielzeug und Werkzeug machen.

Was hat dich an deinen Approval-Entscheidungen wirklich überrascht? Wenn du selbst Agenten baust und das Thema dich umtreibt, schreib mir — ich sammle Ansätze.

GitHub umbenannt, Seite tot — und fünf Tage merkt es niemand

2026-05-12T00:00:00Z

Ich habe einen GitHub-Account umbenannt. Eine Kosmetik-Sache, dachte ich — alter Name, neuer Name, fertig. git push lief direkt danach ohne Murren. Commits landeten im Repo. Lokal war alles grün. Die Sache war abgehakt, bevor sie überhaupt eine Sache war.

Fünf Tage später fiel mir auf, dass die Live-Seite Dinge nicht zeigte, die ich längst gepusht hatte. Kein Deploy-Fehler im Dashboard, keine Fehlermeldung, keine rote Pipeline. Die Seite war einfach auf einem Stand von vor fünf Tagen eingefroren — und zwar genau ab dem Tag des Renames.

Was wirklich passiert war

Ein Account-Rename auf GitHub ist großzügig mit Weiterleitungen. Die alten Clone-URLs antworten mit einem 301-Redirect auf die neuen. Deshalb funktionierte git push sofort weiter: Mein lokales Remote zeigte auf die alte URL, GitHub leitete um, der Push kam an. Genau dieser reibungslose Moment war die Falle — er suggerierte, dass „alles automatisch nachzieht".

Was nicht nachzieht, ist die Webhook-Zustellung. Hosting-Plattformen wie Cloudflare Pages, Vercel oder Netlify hängen ihren Auto-Deploy an einen Webhook, der bei jedem Push feuert. Dieser Webhook ist aber nicht an den Namen gebunden, sondern an die interne Repo-Identität, die bei der Verbindung registriert wurde. Nach dem Rename feuert GitHub die Events weiter — aber die Plattform-seitige Bindung passt nicht mehr sauber, und die Zustellung versandet. Der Build-Hook wird nie ausgelöst. Es gibt keinen fehlgeschlagenen Deploy, weil gar kein Deploy versucht wird.

Das ist das Heimtückische: Ein fehlgeschlagener Deploy ist sichtbar — rote Markierung, Log, Alert. Ein nicht ausgelöster Deploy ist unsichtbar. Das Dashboard zeigt den letzten erfolgreichen Build, der einfach von vor fünf Tagen ist, und nichts deutet darauf hin, dass seitdem etwas hätte passieren sollen.

Warum die Standard-Annahme falsch ist

Der Gedanke „GitHub kümmert sich um die Weiterleitung, also folgt alles" stimmt — aber nur für Clone-URLs. Für git ist der Rename transparent. Für die Event-Zustellung an Drittsysteme ist er es nicht. Die 301-Redirects decken den Pull/Push-Pfad ab, nicht den Push-löst-Webhook-löst-Deploy-Pfad.

Diese Asymmetrie ist der ganze Bug. Man sieht den einen Pfad funktionieren (git push klappt) und schließt daraus auf den anderen (Deploy läuft auch). Aber die beiden teilen sich nichts außer dem Auslöser. Der eine ist robust gegen Renames, der andere nicht.

Die 30-Sekunden-Diagnose

Was hilft, ist ein billiger externer Check, der nicht dem Dashboard glaubt, sondern die Live-Seite selbst befragt. Drei orthogonale Indikatoren, in dreißig Sekunden:

Sitemap-Datum: curl -s https://<site>/sitemap.xml | grep lastmod — steht da ein frisches Datum oder ein altes?
Build-Asset-Hash: Der Hash im Dateinamen des Haupt-Bundles (index-<hash>.js) ändert sich bei jedem Build. Bleibt er gleich, wurde nicht neu gebaut.
Content-Type/Status: curl -sI https://<site>/<datei> — antwortet die Seite überhaupt wie erwartet?

Drei verschiedene Blickwinkel, weil ein einzelner trügen kann: Ein Cache kann ein altes Asset ausliefern, eine Sitemap kann statisch sein. Wenn aber alle drei auf „alt" stehen, ist klar, dass kein Deploy mehr durchläuft.

Der eigentliche Fix war banal: im Plattform-Dashboard das Repo neu verbinden. Eine Minute Arbeit — sobald man weiß, dass es nötig ist.

Die Lektion: stille Fehler brauchen eigene Sensoren

Der teure Teil war nicht der Fix, sondern die fünf Tage. Fünf Tage, in denen ich glaubte, deployt zu haben, während nichts ankam. Stille Fehler — die, die keinen Alarm auslösen — sind die teuersten, weil die Zeit bis zur Entdeckung allein von Zufall abhängt. Hier war es Zufall, dass mir nach fünf Tagen etwas auffiel. Es hätten auch zwei Wochen sein können.

Die verallgemeinerbare Lehre: Nach jedem Account- oder Org-Rename müssen alle Webhook-getriebenen Integrationen — Hosting, CI, Bots — bewusst neu verbunden werden. Und für alles, was „eigentlich automatisch" passieren soll, lohnt sich ein billiger Indikator, der das Ergebnis von außen prüft, statt der internen Statusanzeige zu vertrauen. Ein Dashboard, das sagt „letzter Build erfolgreich", beantwortet nicht die Frage „ist der aktuelle Stand live".

Was offen ist

Der manuelle 30-Sekunden-Check ist gut für den akuten Fall, aber er ist eben manuell — er hilft nur, wenn man ihn ausführt. Die saubere Lösung wäre eine kleine Deploy-Freshness-Probe im Monitoring: ein periodischer Abgleich zwischen dem letzten Commit-Datum und dem Sitemap-/Asset-Stand der Live-Seite, der Alarm schlägt, wenn beide zu weit auseinanderlaufen. Bis das steht, bleibt die Konvention: nach jedem Rename die Hosting-Bindungen anfassen, nicht darauf vertrauen, dass git push genügt.

Welcher „erledigte" Infrastruktur-Schritt hat dich später eingeholt — und wie hast du gemerkt, dass etwas still kaputt war? Schreib mir.

Ein Script hing 14 Minuten ohne Fehler — der Pipe-Buffer war voll

2026-04-17T00:00:00Z

Das Skript lief seit Wochen. Es rief ein externes Tool auf, las dessen JSON-Ausgabe und verarbeitete sie weiter — bei NotebookLM-Extraktionen, yt-dlp-Abrufen, allem, was strukturierte Antworten liefert. Dann, eines Tages, hing es. Vierzehn Minuten lang. Kein Fehler, kein Stacktrace, kein Timeout. Nur ein Prozess, der dastand und nichts tat.

Das Tückische an diesem Fehler ist, dass er nicht aussieht wie ein Fehler. Ein Crash hat einen Stacktrace, den man lesen kann. Ein Timeout hat eine Meldung. Ein Deadlock hat nichts — er ist die Abwesenheit von Fortschritt, und die ist schwer von „dauert halt lange" zu unterscheiden.

Was das Script tat

Der Aufruf war Standard: subprocess.run(cmd, capture_output=True, text=True). capture_output=True ist die bequeme Variante — sie sammelt stdout und stderr ein und gibt sie als fertige Strings zurück. Für die allermeisten Aufrufe ist das genau richtig: Befehl läuft, produziert ein bisschen Ausgabe, Python liest sie ein, fertig.

Der Unterschied an diesem Tag: Die Antwort war groß. Rund 314 KB JSON. Und genau bei dieser Größenordnung kippt das Verhalten.

Warum ein voller Puffer alles anhält

Zwischen einem Eltern- und einem Kindprozess liegt eine Pipe — ein Betriebssystem-Puffer mit begrenzter Größe. Unter Windows sind das je nach Konfiguration nur einige zehn Kilobyte. Der Kindprozess schreibt seine Ausgabe in diese Pipe; der Elternprozess liest sie heraus und macht Platz für mehr.

Das funktioniert, solange jemand auf der anderen Seite liest. subprocess.run mit capture_output=True liest aber erst, nachdem der Kindprozess fertig ist — vereinfacht gesagt: es wartet auf das Ende, dann holt es die Ausgabe ab. Bei kleiner Ausgabe ist das egal: alles passt in den Puffer, der Kindprozess schreibt fertig, beendet sich, der Elternprozess liest. Bei großer Ausgabe entsteht ein Patt: Der Kindprozess füllt den Puffer, will weiterschreiben, kann aber nicht, weil niemand abräumt — also blockiert er. Der Elternprozess wartet darauf, dass der Kindprozess sich beendet — was nie passiert, weil der Kindprozess am Schreiben hängt. Beide warten aufeinander. Das ist der Deadlock.

Verschärft wird es, wenn stdout und stderr gleichzeitig volllaufen. Dann ist jede Pipe für sich ein potenzieller Hängepunkt, und es reicht, dass eine von beiden den Puffer füllt.

Die vierzehn Minuten waren übrigens kein „es lief langsam" — es lief gar nicht. Der Prozess wäre auch nach vierzehn Stunden noch dagestanden.

Die Lösung: nicht in den Speicher, sondern auf die Platte

Der Fix ist unspektakulär: Bei potenziell großer Ausgabe nicht capture_output=True verwenden, sondern stdout auf eine temporäre Datei umleiten — subprocess.run(cmd, stdout=open(tmp, "wb")). Das Betriebssystem schreibt direkt in die Datei, der Puffer läuft nie voll, der Kindprozess blockiert nie. Danach liest Python die Datei ein.

Das ist langsamer als der Speicher-Weg — ein zusätzlicher Schreib-/Lese-Vorgang auf die Platte. Aber „langsamer und korrekt" schlägt „schnell und hängend" in jeder Bilanz. Die saubere, stdlib-korrekte Alternative wären nebenläufige Threads, die beide Pipes parallel leeren (genau das tut subprocess.communicate() intern) — aber für ein Tool, das ohnehin große Dateien produziert, ist die Temp-Datei der einfachere und robustere Weg.

Die Faustregel, die daraus wurde: Sobald eine Subprozess-Ausgabe potenziell über etwa 50 KB gehen kann, ist capture_output=True ein Risiko, kein Komfort.

Stille ist die schlimmste Fehlermeldung

Die eigentliche Lektion ist weniger technisch als diagnostisch. Dieser Bug war so lange unentdeckt, weil er sich nur bei großen Eingaben zeigte — und große Eingaben waren der Ausnahmefall. „Funktioniert mit kleinen Daten" ist ein verräterisches grünes Licht: Es verdeckt jede Klasse von Fehlern, die erst an der Pufferung, am Speicher oder an der Datenmenge hängt.

Und weil der Fehler sich als Stille äußert, ist er teuer zu diagnostizieren. Bei einem Crash sucht man nach der Ursache. Bei einem Hang sucht man erst einmal nach der Frage, ob überhaupt etwas kaputt ist. Die Antwort fand sich nicht im eigenen Code, sondern im Verständnis dessen, was zwischen den Prozessen passiert — in der Pipe, die man normalerweise nie sieht.

Was offen ist

Der Temp-Datei-Fix ist robust, aber er ist eine Behandlung des Symptoms am Aufrufpunkt. Die saubere Lösung wäre, große Antworten gar nicht erst als ein einzelnes JSON-Blob über die Pipe zu schieben, sondern zu streamen — zeilenweise oder in Chunks, sodass nie eine große Menge auf einmal im Puffer liegt. Das verlangt aber, dass auch das aufgerufene Tool Streaming unterstützt, und nicht jedes tut das.

Bis dahin gilt die einfache Regel: Bei allem, was groß werden kann, geht die Ausgabe auf die Platte, nicht in den Speicher. Es ist nicht elegant. Aber es hängt nicht.

Hattest du schon einen Prozess, der ohne Fehler einfach stehenblieb — und wie lange hat es gedauert, bis du den Puffer im Verdacht hattest? Schreib mir.

Erste Woche, drei Subprocess-Fehler — wie der Bot lernte, auf Windows zu sprechen

2026-03-29T00:00:00Z

Der Dynamic Central Orchestrator fing klein an: ein Telegram-Bot, der eingehende Nachrichten an die Claude-CLI weiterreicht und die Antwort zurückschickt. Im Prinzip ein Einzeiler — subprocess.run(["claude", "-p", prompt]). In der Praxis war es drei Tage Lehrgeld, verteilt auf drei Fehler, die nichts miteinander zu tun hatten außer dem Ort, an dem sie passierten: der Grenze zwischen meinem Python-Prozess und einem anderen Programm auf Windows.

Fehler 1: Windows findet das Programm nicht

Der erste Lauf endete mit FileNotFoundError: [WinError 2]. Im Terminal lief claude problemlos — also musste es ja installiert sein. Der Bot sah es trotzdem nicht.

Der Grund: Ein Service- oder Hintergrundprozess erbt nicht denselben PATH wie meine interaktive Shell. Wenn ich claude in die Konsole tippe, durchsucht die Shell ihren PATH und findet den npm-Wrapper. Mein Python-Prozess, gestartet aus einem anderen Kontext, hatte diesen PATH-Eintrag nicht. Für mich war das Programm „da". Für den Subprozess existierte es nicht.

Die Lösung war nicht, den Befehl anders zu schreiben, sondern ihn vorher aufzulösen: shutil.which("claude") durchsucht den PATH des laufenden Prozesses und gibt den absoluten Pfad zurück — oder None, wenn nichts gefunden wird. Diesen absoluten Pfad übergebe ich dann an subprocess.run. Aus „verlass dich darauf, dass das Programm im PATH ist" wird „finde es einmal, sauber, und scheitere laut, wenn es fehlt".

Fehler 2: aus „für" wird „fÃ¼r"

Der nächste Lauf funktionierte — fast. Die Antworten kamen zurück, aber jeder Umlaut war zerschossen. „für" wurde zu „fÃ¼r", „schön" zu „schÃ¶n". Klassisches Mojibake: UTF-8-Bytes, durch eine Latin-1-Brille gelesen.

Windows ist hier eine besondere Falle, weil die Standard-Konsolen-Codepage nicht UTF-8 ist. Wenn Text als Kommandozeilen-Argument durch die Prozessgrenze geht, hängt die Kodierung von Dingen ab, die ich nicht kontrolliere — der Codepage des Eltern- und des Kindprozesses. Ein Prompt mit deutschen Umlauten wird unterwegs umkodiert, und niemand fragt mich, ob das so gewollt war.

Der Fix war eine Verschiebung des Übergabewegs: nicht den Prompt als Argument anhängen, sondern über stdin einspeisen — subprocess.run(cmd, input=prompt, encoding="utf-8"). Über stdin ist der Text ein Datenstrom mit expliziter Kodierung, kein von der Shell interpretiertes Argument. Das löst gleich zwei Probleme auf einmal: die Umlaute bleiben heil, und lange oder sonderzeichen-haltige Prompts werden nicht vom Quoting der Shell zerlegt. Letzteres wurde später, bei den .cmd-Wrappern, noch zu einer eigenen Geschichte.

Fehler 3: der Bot vergisst, worüber wir reden

Jetzt liefen die Aufrufe sauber durch — aber der Bot hatte kein Gedächtnis. Jede Nachricht war für ihn die erste. „Und dann?" war eine sinnlose Frage, weil es kein „davor" gab.

Das ist kein Subprocess-Bug im engeren Sinn, aber es ist dieselbe Klasse: Ein frisch gestarteter Prozess hat genau den Kontext, den ich ihm mitgebe — und keinen Zeichen mehr. Der CLI-Aufruf ist zustandslos. Wenn ich Gesprächsverlauf will, muss ich ihn selbst zusammenbauen und mitschicken.

Die naive Variante — einfach alle bisherigen Nachrichten aneinanderhängen — produziert schnell Matsch, in dem das Modell nicht mehr unterscheiden kann, was meine Eingabe war und was seine eigene frühere Antwort. Es braucht klare Trennmarken: wer hat was gesagt, wo endet ein Beitrag, wo beginnt der nächste. Erst mit strukturiertem Verlauf statt einem Textbrei wurde aus den Einzelaufrufen ein Gespräch.

Drei Fehler, ein Muster

Im Rückblick war keiner dieser Fehler schwer. Jeder einzelne war eine Stunde Recherche und eine Zeile Code. Was sie verbindet, ist die Stelle, an der sie auftraten — und die Annahme, die sie alle teilten: dass ein anderes Programm aufzurufen „einfach" ist.

Ist es nicht. Auf Windows zerfällt „ein Programm aufrufen" in mindestens drei getrennte Probleme: Wird das Programm überhaupt gefunden? Kommt der Text unverfälscht an? Hat der Aufruf genug Kontext, um sinnvoll zu antworten? Jedes davon ist unsichtbar, bis man es trifft, und keines verrät sich vorher.

Die teuerste Annahme war „funktioniert in meinem Terminal". Mein Terminal hat den richtigen PATH, eine UTF-8-fähige Konsole und einen Menschen, der den Kontext im Kopf hat. Ein Bot-Prozess hat nichts davon automatisch. Die Lücke zwischen „läuft bei mir interaktiv" und „läuft als Dienst" ist genau die Lücke, in der diese drei Fehler wohnen.

Was offen ist

Die hier beschriebenen Fixes sind robust, aber sie sind projektspezifisch zusammengesucht. Was fehlt, ist eine saubere Abstraktion: eine kleine Wrapper-Funktion, die shutil.which auflöst, stdin mit UTF-8 erzwingt und Fehler einheitlich behandelt — einmal richtig gebaut, überall wiederverwendet. Stattdessen sind die Lehren über mehrere Projekte verteilt als Konventionen dokumentiert und werden bei jedem neuen Subprozess-Aufruf einzeln angewendet. Das funktioniert, ist aber fehleranfällig: Wer die Konvention nicht kennt, baut Fehler 1 bis 3 frisch nach.

Die ehrliche Bilanz nach der ersten Woche: Der Bot konnte sprechen. Aber dass „mit einem anderen Programm reden" so viel Reibung erzeugt, war die erste echte Lektion des Projekts — und eine, die sich danach in jedem weiteren Windows-Subprozess wiederholt hat.

Welcher Subprocess-Aufruf hat dich am längsten gekostet — und woran lag es am Ende wirklich? Wenn du an ähnlichen Integrationen arbeitest, schreib mir.