Claude Code 2.1.199 bis 2.1.201: die Defaults wandern zurück zum Menschen

Version 2.1.198 hat die Übergabe in den Draft-PR verlegt: Hintergrund-Agenten liefern fertige Arbeit als prüfbares Artefakt, statt anzuhalten und zu fragen. Die drei Versionen danach, 2.1.199 vom 2. Juli sowie 2.1.200 und 2.1.201 vom 3. Juli, beantworten die Frage, die dabei offen blieb: Wie weit trauen Sie einem Lauf, bei dem niemand zusieht? Anthropics Antwort in diesem Changelog fällt auf. Der Standardmodus für Berechtigungen heißt jetzt „Manual“, Rückfragen laufen nicht mehr von allein weiter, und Sub-Agenten dürfen Fehler nicht mehr als Erfolg melden. Der Hersteller dreht die Vertrauens-Defaults zurück in Richtung Aufsicht.

Was ändert sich an den Defaults?

Zwei Einträge in 2.1.200. Erstens: Der Berechtigungsmodus, der bisher schlicht „default“ hieß, heißt jetzt überall „Manual“, in der CLI, in --help, in VS Code und JetBrains. --permission-mode manual und "defaultMode": "manual" werden neben defaultakzeptiert. Technisch ist das eine Umbenennung, kein neues Verhalten. Trotzdem halte ich sie für den interessantesten Eintrag der Woche. „Default“ sagt nur, was passiert, wenn Sie nichts entscheiden. „Manual“ sagt, was der Modus tut: Der Mensch gibt frei. Der Name legt offen, dass die Grundeinstellung des Werkzeugs die menschliche Freigabe ist und alles andere eine Abweichung davon. Zweitens: AskUserQuestion-Dialoge laufen nicht mehr automatisch weiter. Bisher konnte eine Rückfrage, die Sie nicht beantworteten, nach einer Wartezeit von allein weitergehen. Jetzt bleibt die Frage stehen, bis Sie antworten. Wer den Idle-Timeout will, schaltet ihn über /config bewusst ein. Eine Frage an den Menschen ist wieder eine Frage, keine Formalie mit Ablaufdatum.

Warum ist der Sub-Agenten-Fix der wichtigste Eintrag?

Weil er die Wahrheit der Signale betrifft. 2.1.199 behebt einen Fehler, der es in sich hat: Sub-Agenten meldeten API-Fehler, etwa ein erreichtes Nutzungslimit, als erfolgreiche Ergebnisse. Jetzt wird der Fehler an den übergeordneten Agenten durchgereicht. Dazu passt der Rest der Serie: Sub-Agenten, die ein Rate-Limit oder ein Serverfehler abschneidet, scheitern nicht mehr still, sondern geben ihre Teilarbeit an den Parent zurück. 2.1.200 ergänzt den Randfall, dass ein Sub-Agent, der noch gar keinen Text produziert hat, sauber scheitert, statt ein leeres Ergebnis zu liefern. Und abgebrochene Streams werfen die Teilausgabe nicht mehr weg, sondern behalten sie mit einem Hinweis auf die unvollständige Antwort. Meine Einordnung: In einer Orchestrierung ist das gemeldete Ergebnis des Sub-Agenten die einzige Wahrheit, die der übergeordnete Agent hat. Ein „Erfolg“, der in Wirklichkeit ein Nutzungslimit war, vergiftet alles, was darauf aufbaut, und kein noch so fähiges Modell an der Spitze kann das korrigieren. Verlässlichkeit liegt hier nicht im Modell, sondern in der Architektur der Fehlermeldungen.

Was erzählen die Daemon-Fixes über unbeaufsichtigte Läufe?

Die lange Liste der Hintergrund-Fixes liest sich wie ein Katalog der Dinge, die schiefgehen, wenn niemand hinsieht. Ein verwaistes daemon.lock, dessen Prozess-ID das Betriebssystem wiederverwendet hat, verhinderte jeden Neustart der Hintergrund-Agenten. Unter Linux beendete sich der Daemon nach einem unsauberen Shutdown alle rund 50 Sekunden selbst, samt aller laufenden Agenten. Sitzungen blieben nach dem Aufwachen des Rechners still stehen. Und claude stopkonnte wirkungslos verpuffen, wenn es zeitgleich mit einem automatischen Neustart eintraf. Auffällig ist, wie oft das Wort „silently“ im Changelog steht. Das sind Fehlermodi, die nur auffallen, wenn jemand hinschaut. Bei einem unbeaufsichtigten Lauf schaut per Definition niemand hin. Genau deshalb gehören solche Fixes zur selben Geschichte wie die Defaults: Bevor man Läufen ohne Aufsicht traut, muss der Unterbau aufhören, still zu scheitern. Der Vollständigkeit halber: 2.1.201 enthält genau einen Eintrag zur internen Prompt-Mechanik von Sonnet 5 und spielt für diese Geschichte keine Rolle.

Was heißt das für den Alltag?

Zwei Tage nachdem der Draft-PR die unbeaufsichtigte Übergabe zum Normalfall gemacht hat, zieht derselbe Hersteller die Grenzen nach: Freigaben heißen Manual, Rückfragen warten auf Antwort, Fehler heißen Fehler. Ich lese das nicht als Widerspruch, sondern als die richtige Reihenfolge. Autonomie soll eine bewusste Entscheidung sein, per /config oder Flag, nicht eine Voreinstellung, in die man hineinstolpert. Es ist dieselbe Linie wie im Agentic Engineering: Die Fähigkeit der Agenten wächst schneller als ihre Prüfbarkeit, und die Prüfung bleibt beim Menschen. Wenn selbst der Anbieter, der am meisten von autonomen Läufen hätte, seine Defaults auf menschliche Freigabe stellt, ist das ein Datenpunkt, den Sie in Ihre eigenen Voreinstellungen übernehmen sollten. Aufsicht abschalten kann man immer noch. Absichtlich, nicht aus Versehen.

Quellen

• Claude Code: Changelog