Umzug nach Linux – und entschlacken

Bis Anfang November liefen meine Agenten unter Windows in Git Bash. Am Anfang wollte ich nur testen, damit alles sicher ist, doch die Testsuite von Kettenhemd brauchte dort 36 bis 49 Minuten. Ich saß sehr viel vor der Konsole und fragte mich, warum es so lange dauerte und warum hier und da Timeouts in der Suite auftauchten. Das hat so unglaublich genervt.

Ich stellte die klassische Frage, wie andere es machen, und probierte alles von einer eigenen CI, damit es schneller geht, bis zum Aufsplitten der Suite. Ein Grund lag tief im System. Ein leeres Programm brauchte unter Git Bash bei laufendem Virenschutz und unter Last 0,36 Sekunden je Start, und jeder Testfall startet einige Dutzend Programme wie git, grep und sed. Obendrein standen im Regeltext zwei Dutzend Sonderregeln für Windows, etwa um Pfade umzuwandeln, bestimmte Zeichen nur über Dateien zu übergeben und eigene Befehle zum Öffnen zu nutzen. Sechs von 25 Fallstricken, die Kettenhemd gesammelt hatte, drehten sich um Windows.

18 Sekunden

Der Außenblick aus Teil 2 hatte Linux ganz nach vorn gestellt. Am Abend des 2. November setzte ich auf demselben Rechner unter WSL2 eine frische Linux-Umgebung auf, und dort lief die ganze Suite in 17,9 Sekunden durch. Das war absolut glorreich. Am liebsten hätte ich sofort komplett zu Linux gewechselt, das war endlich mal ein riesiger Erfolg.

WSL2 ist dabei kein Emulator; Windows startet vielmehr einen echten Linux-Kern in einer kleinen virtuellen Maschine, die es selbst verwaltet. Microsoft rät dazu, die Projektdateien im Dateisystem der Werkzeuge abzulegen, die damit arbeiten, weil der Weg zwischen Windows- und Linux-Dateien langsam ist (Microsoft: WSL-Versionen im Vergleich). So liegen meine Repos jetzt in Linux.

Ein Prozentzeichen zu viel

Noch am selben Abend kam der Rückschlag, als ein Referenzlauf, also ein Testlauf von Kettenhemd an einem erfundenen Projekt, abbrach. Die Sessions starteten mit leerem PATH, fanden keinen Befehl mehr, und der Agent meldete: „Die Pflichtprüfung ist nicht gelaufen und das Issue steht still.“

Die Ursache war noch am selben Abend belegt. Mein Plugin führt beim Start jeder Session einen Hook aus, einen Befehl, den Claude Code selbst aufruft, und dieser Hook benutzte printf %q, um den Pfad sicher zu schreiben. Claude Code führt Hooks allerdings mit /bin/sh aus, und unter Ubuntu ist das dash, eine schlanke Shell nach POSIX. Deren printf kennt %q nicht (Handbuchseite zu dash), und heraus kam export PATH=, ein Pfad ohne Inhalt.

Neu war der Fehler nicht. Mein Server läuft unter Linux und hatte ihn am 29. Oktober gemeldet, doch dort war die Ursache fünf Tage lang rätselhaft geblieben. Jetzt ging sie an den Server zurück.

Der Umzug

Am Morgen des 3. November lief der Referenzlauf noch einmal. In 28 Protokollen fand sich kein einziger Fehler durch Pfade, und alle sechs Aufgaben bestanden die erste Reviewer-Runde, also die erste Prüfung durch den Reviewer-Agenten. Der Richtwert der Kosten, den Claude Code je Session anzeigt, lag 5 Prozent über dem Ausgangswert. Eine echte Rechnung ist das nicht – ich nutze das Abo Claude Ultra.

Am Vortag hatte ich noch gesagt, erst die Updates abwarten, und am Morgen hieß es noch einmal „Erstmal warten“. Mittags kam das Ja für alle Entwicklungsprojekte, auch wenn ich nicht mehr weiß, was dazwischen den Ausschlag gab. Jedes Projekt läuft seitdem als eigener Dienst, der nach einem Absturz von selbst neu startet.

Am späten Nachmittag brachen sieben Konsolen jede Minute mit der Meldung „Workspace not trusted“ ab. Claude Code muss jedem Ordner einmal vertrauen, und das hatte niemand eingetragen. Kurz darauf meldeten sechs Projekte, dass git nicht im PATH sei – es war derselbe Fehler vom Vorabend. Die Behebung steckte erst im Entwurf der nächsten Version, während noch die alte ausgerollt war.

Ich war ein wenig verloren, weil ich mich selbst mit Linux nicht gut auskannte. Ohne Agenten konnte ich nicht genau sehen, was passiert war. Ich hatte zwar eine Vermutung, konnte aber die Anleitung nicht verfolgen. Also habe ich Claude in der Desktop-App normal gestartet und den Fehler gründlich analysiert, und danach war das Thema geklärt. Die Zwischenlösung war Handarbeit – eine Datei aus dem neuen Plugin-Entwurf an die Stelle der alten setzen und dann die sechs Konsolen neu starten. Das Vertrauen trägt seitdem das Einrichtungsskript selbst ein, und am Schluss hatten wir eine richtig gute Anleitung, die uns beim nächsten Mal hilft.

Was weg ist

Am Abend liefen acht Konsolen als Dienste, und das Aufräumen begann. Der Windows-Bezug im Regeltext schrumpfte von 23 Zeilen auf 2, wobei ein Skript seitdem mitzählt und abbricht, sobald eine dritte dazukommt.

Archiviert habe ich auch Torwache, das Werkzeug, das unter Windows meine Konsolen startete. Ich fand es schade; Torwache war ein schöner Oneshot, der Spaß gemacht hat und in dem ich sehen konnte, dass die Konsolen an sind und neu starten. Jetzt läuft das in Linux versteckt als Dienst, und aktuell bleibt alles ein wenig „unbekannt im Dunkeln“.

Überrascht hat mich, wie einfach es am Schluss war. WSL2 ist zwar Linux unter Windows, aber es ging ohne Probleme. Mein Rechner bleibt ein normaler Windows-Rechner, und das Entwickeln geht schneller.

Einfrieren, aber womit

Jetzt folgt der zweite Schritt aus dem Plan, und nach Version 17 friere ich Kettenhemd ein. Es gibt keine neue Version, bis 20 echte Aufgaben in mindestens zwei Produktprojekten erledigt sind, höchstens vier Wochen lang; echt heißt dabei, dass die Aufgabe nicht von Kettenhemd selbst kommt. Gemessen werden Durchlaufzeit, Kosten, Review-Runden und Folge-Issues in den 14 Tagen danach. Dann wird der Regeltext gekürzt – für eine Untersession, die eine Aufgabe umsetzt, von 62 auf höchstens 30 KB, für den Reviewer von 79 auf höchstens 40 KB. Neue Regeln gibt es danach nur noch nach einem echten Vorfall.

Begonnen hat das noch nicht. Version 17 ist bis heute nicht ausgerollt, und im Issue zur Bewährung steht ein Satz, der den Plan auf den Kopf stellt. Mein Fokus lag auf Kettenhemd, an anderen Projekten habe ich zuletzt nicht gearbeitet, und 20 echte Aufgaben waren so nicht absehbar. Das wird sich ändern. In der Zeit habe ich genug Ideen und Projekte gesammelt, die ich jetzt starten kann.

Eine Regel gegen ein Problem war schnell geschrieben, und 23 Zeilen davon hatten sich angesammelt, doch das Problem selbst loszuwerden, hat an einem Tag mehr gebracht. Wer seine Agenten heute unter Windows laufen lässt, dem rate ich trotzdem nicht zum sofortigen Wechsel. Linux hat seine Vorteile, aber erst, wenn man den Prozess wirklich optimieren möchte. Fang unter Windows an und wechsle, wenn Probleme auftreten – und selbst wenn du es tust, ist das wirklich nicht schwer.

Diesen Beitrag hat mein Agent aus einem Interview mit mir geschrieben; Zahlen und Abläufe stammen aus Kettenhemd. Gelesen und freigegeben habe ich ihn selbst.