Claude Code v2.1.199 wurde am 2026-07-02 um 23:35:18 UTC veröffentlicht, einen Tag nach v2.1.198 (dem Chrome-GA- + Hintergrund-Agenten-Auto-PR- + /dataviz- + Gateway-auf-AWS-Release) und zwei Tage nachdem v2.1.197 Sonnet 5 zum Standardmodell gemacht hat. Die Versionshinweise sind ungewöhnlich lang für einen Eintages-Zyklus: 24 Changelog-Einträge, ein neues Feature und 23 Fehlerbehebungen, mit einer Fix-Liste, die auf derselben Fläche konzentriert ist, die v2.1.198 erweitert hat (Hintergrund-Agenten, Sub-Agenten, der Auto-PR-Workflow, Plan-Mode), plus einem langen Schwanz kleinerer UX-Fixes. Das Muster passt zu den beiden vorherigen Versionen: Anthropic iteriert die v2.1.19x-Linie im selben Tempo wie das zugrundeliegende Modell, und die Produktoberfläche für Sonnet 5 wird Release für Release gehärtet.
Das eine neue Feature: gestapelte Slash-Skill-Aufrufe
Das einzige neue Feature in v2.1.199 ist eine kleine, aber nützliche Erweiterung der Slash-Skill-Fläche. In v2.1.198 und früher lud ein Prompt wie /skill-a /skill-b do XYZ nur die erste Skill, skill-a; das zweite /skill-b wurde als Teil des Prompt-Textes behandelt, nicht als weiterer Skill-Aufruf. v2.1.199 ändert die Regel: der Parser geht die führenden Token des Prompts durch und lädt bis zu 5 Slash-Skills, bevor er auf den Rest der Nachricht zurückfällt. Ein Kommando wie /plan /review /dataviz do XYZ lädt nun plan, review und dataviz als aktiven Skill-Satz, statt nur plan zu laden und den Rest stillschweigend zu verwerfen.
Die Deckelung auf 5 Skills ist ein Schutzzaun, keine Feature-Obergrenze: Skills tragen ihren eigenen Kontext und ihre eigene Werkzeug-Fläche, und eine sechste Skill wäre genau die Form von Prompt, die bereits einen eigenen Sub-Agenten statt einer Inline-Skill-Kette rechtfertigt. Die Deckelung ist großzügig für die üblichen Fälle (2 bis 3 Skills, um einen Planungsschritt, einen Code-Review-Schritt und einen Visualisierungsschritt zu kombinieren) und konservativ für die Randfälle (ein übereifriger Agent, der sonst in einem halben Dutzend sich überlappender Skill-Kontexte hineinrutschen würde). Die Änderung ist additiv: bestehende Einzel-Skill-Aufrufe sind unverändert, und ein Nutzer, der nur eine Skill im Geltungsbereich möchte, kann weiterhin /skill-a do XYZ schreiben und erhält dasselbe Verhalten wie zuvor.
Fehlerberichte der Sub-Agenten und Wiederherstellung der Teilarbeit
Der tiefste Cluster von Fixes in v2.1.199 liegt in der Sub-Agenten- / Hintergrund-Agenten-Fläche, und drei davon betreffen die Sichtbarkeit von Fehlern für den übergeordneten Agenten. In v2.1.198 und früher versteckten drei unabhängige Fehlermodi die Teilarbeit vor dem Orchestrator:
- Sub-Agenten, die durch eine Ratenbegrenzung oder einen Server-Fehler abgeschnitten wurden, schlugen stillschweigend fehl. Ein Sub-Agent, dem der Kontext ausging, der einen 429 traf oder einen 5xx von der API erhielt, gab nichts an den Parent zurück. Der Parent hatte keine Möglichkeit, zwischen einer unvollendeten Aufgabe und einer nie begonnenen Aufgabe zu unterscheiden, und die Teilarbeit, die der Sub-Agent bereits geleistet hatte, ging verloren.
- Sub-Agenten meldeten API-Fehler als erfolgreiche Ergebnisse. Ein Sub-Agent, der mitten in der Aufgabe auf einen API-Fehler stieß (Nutzungslimit-Fehler, 529 Overloaded, Modellfehler), gab eine Ergebnis-Hülle an den Parent zurück, mit dem Fehler als Text innerhalb des Ergebnisses. Der Parent behandelte die Hülle als Erfolg und verwendete den Fehlertext als Antwort.
SendMessageroutete stillschweigend falsch, wenn ein neu gestarteter Agent den Namen eines vorherigen Agenten wiederverwendete. Wenn ein Agent starb und ein neuer Agent im Agenten-Panel seinen Namen übernahm, konnte ein nachfolgendesSendMessagegelegentlich auf den Datensatz des toten Agenten treffen und auf eine veraltete Konversation routen. Der Parent erhielt keinen Fehler, nur eine fehlende Antwort.
v2.1.199 behebt alle drei. Sub-Agenten, die durch eine Ratenbegrenzung oder einen Server-Fehler abgeschnitten werden, geben nun ihre Teilarbeit an den Parent zurück, mit dem Fehler im Anhang. Sub-Agenten, die auf einen API-Fehler stoßen, melden den Fehler nun an den Parent, wobei die Teilarbeit in einem separaten Feld der Ergebnis-Hülle erhalten bleibt. SendMessage erkennt die Namensabweichung und bittet den Aufrufer, das Ziel neu zu wählen, und legt das Routing-Problem als Tool-Fehler offen, statt es stillschweigend zu verschlucken. Das Muster entspricht dem v2.1.198-Fix für Agent-Teams (ein Teamkollege, der an einem API-Fehler stirbt, meldet dem Lead nun failed), und beide Releases verwandeln gemeinsam den Ausfallmodus der v2.1.196-Ära „Sub-Agenten sehen aus, als wären sie erfolgreich, sind es aber nicht" in einen sichtbaren, wiederherstellbaren Modus.
Crash-Schleife des Hintergrund-Agenten-Daemon unter Linux
Der betrieblich schmerzhafteste Fix in der Version ist die Crash-Schleife des Hintergrund-Agenten-Daemon unter Linux. Vor v2.1.199 konnte ein harter Abbruch des Daemon (ein kill -9, ein OOM des Hosts, ein Stromausfall, ein Absturz in einem Kindprozess) einen korrumpierten Worker-Datensatz auf der Festplatte im Zustandsverzeichnis des Daemon hinterlassen. Der Wiederherstellungs-Code des Daemon versuchte beim nächsten Start, den Datensatz zu lesen, scheiterte an der Korrumpierung, protokollierte einen Fehler und beendete sich; der Supervisor startete den Daemon neu, der am selben Datensatz scheiterte; und der Zyklus wiederholte sich etwa alle 50 Sekunden. Alle laufenden Hintergrund-Agenten im Arbeitsbereich des Nutzers starben mit dem Daemon.
Die Crash-Schleife ist die Art von Problem, die bei langlebigen CI- und dashboard-gestützten Worktree-Agenten auftritt, nicht bei interaktiver Einsitz-Verwendung, was erklärt, warum sie zwei Versionen nachdem v2.1.198 den Auto-PR-Flow zum Standard für Hintergrund-Agenten gemacht hat, kommt. v2.1.199 repariert den Wiederherstellungs-Code so, dass der korrumpierte Datensatz erkannt und durch einen frischen ersetzt wird, statt den Daemon abstürzen zu lassen; der Supervisor-Respawn ist nun eine Wiederherstellungs-Aktion, kein wiederkehrender Fehler. Die Version behebt außerdem eine verwandte Regression aus v2.1.196: Hintergrund-Agenten, die auf SSH-macOS einen Cold-Start versuchten, schlugen mit Could not switch to audit session fehl, was den SSH-auf-macOS-Startpfad für Teams unbenutzbar machte, die Claude Code auf einem entfernten Mac laufen lassen. Der Fix ist eine einzeilige Änderung im SSH-Start-Wrapper, die explizit die Audit-Session umschaltet, bevor der Agent versucht, sich an sie zu binden.
Erhaltung von Streaming-Antworten bei API-Fehlern mitten im Stream
Zwei verwandte Fixes zielen auf den Moment, in dem ein Modell-Aufruf in Flug ist und die API ihn abschneidet. Der erste ist der Streaming-Response-Verlust-Bug: wenn die Anthropic-API einen Overloaded- (529) oder Server-Fehler (5xx) mitten im Stream emittierte, nachdem das Modell bereits eine Teilausgabe produziert hatte, verwarf Claude Code 2.1.198 und früher die Teilantwort zusammen mit dem Fehler und ließ den Nutzer ohne Ergebnis zurück. v2.1.199 behält die Teilausgabe und hängt eine incomplete-response-Notiz an. Die Änderung ist vor allem für lange Generierungen relevant: ein Sonnet-5-Lauf mit 1M-Kontext, ein Multi-File-Refactor mit Tausenden von Tool-Aufrufen, ein /dataviz-Diagramm mit langer Erläuterung, sie alle konnten unter v2.1.198 mehrere Sekunden Arbeit durch einen einzigen späten 529 im Stream verlieren. Der Fix ist mit der neuen Retry-Richtlinie gepaart (siehe unten): ein Teil-Turn wird nicht mehr beim ersten transienten Fehler verschwendet, und die Teilantwort bleibt erhalten, wenn die Retries erschöpft sind.
Der zweite ist die SSL/TLS-Fehlerbehandlung hinter Unternehmens-Proxies. In v2.1.198 und früher verbrannte ein SSL-Handshake-Fehler, verursacht durch einen TLS-Inspektions-Proxy, ein fehlendes NODE_EXTRA_CA_CERTS oder ein abgelaufenes Zertifikat, das gesamte Retry-Budget, bevor irgendein Hinweis angezeigt wurde. v2.1.199 ändert den Pfad: SSL-Fehler schlagen sofort mit einem Korrekturhinweis fehl, der die wahrscheinlichste Ursache benennt (NODE_EXTRA_CA_CERTS für ein fehlendes CA-Bundle, Zertifikatsprüfung für ein abgelaufenes Zertifikat, Proxy-Trust-Store für ein Unternehmens-MITM). Die Änderung ist eine Verbesserung der Fehlerqualität, keine Verhaltensänderung: derselbe Fehler wird nun in einem statt in fünf Turns diagnostiziert, und das Retry-Budget bleibt für transiente Fehler erhalten, die tatsächlich Retries verdienen.
Plan-Mode, Hook-stderr und die claude agents-Ansicht
Die Plan-Mode-Fixes in v2.1.199 sind kleiner, decken aber zwei unterschiedliche Papierschnitte ab. Erstens forderte der Plan-Mode keine Bestätigung für zustandsverändernde Browser-Tool-Aufrufe an; eine Sitzung im Plan-Mode, die versuchte, eine zustandsverändernde Browser-Aktion aufzurufen, erlaubte den Aufruf stillschweigend selbst, anstatt den Nutzer zu fragen. v2.1.199 behält das bestehende Auto-Allow für Read-only-browser_batch-Aufrufe (den sicheren, Read-only-Pfad durch die Chrome-Erweiterung) und fügt die fehlende Bestätigung für zustandsverändernde Browser-Tool-Aufrufe hinzu. Die Aufteilung passt zum v2.1.198-Fix, der Read-only-Tool-Aufrufe auto-allowte, wenn eine Sitzung im Plan-Mode startet, und sie schließt die asymmetrische Behandlung der Read-only- und zustandsverändernden Browser-Tools.
Zweitens versteckten die SessionStart-, Setup- und SubagentStart-Hooks stillschweigend stderr, wenn sie mit Code 2 endeten. Ein Hook, der mit einer fehlenden Abhängigkeit, einem Parse-Fehler oder einer Runtime-Ausnahme fehlschlug, protokollierte nach stderr, endete mit 2 und ließ den Nutzer mit einem erfolgreich aussehenden Hook-Ergebnis zurück. v2.1.199 zeigt das stderr im Transkript, wenn ein Hook nicht-null beendet, sodass ein fehlerhaft arbeitender Hook für den Nutzer sichtbar ist, statt ein stiller Fehler zu sein. Die Änderung zählt aus demselben Grund wie der v2.1.197-MCP-Trust-Fix zählte: ein Hook ist ein nutzergesteuertes Skript, und ein stiller Fehler eines nutzergesteuerten Skripts ist eine Debug-Zeitfalle.
Die Version behebt außerdem einen Bug der claude agents-Ansicht: untätige Sub-Agenten verschwanden aus dem Agenten-Panel, während andere Sub-Agenten noch arbeiteten, was dem Nutzer eine unvollständige Sicht auf seine laufenden Agenten ließ. v2.1.199 fasst überschüssige untätige Agenten in einer aufklappbaren Zusammenfassungs-Zeile zusammen, sodass der Nutzer immer die aktiven Agenten sieht und die Zeile aufklappen kann, um die untätigen zu sehen. Dieselbe Ansicht erhält einen Fix, bei dem das Tippen von /model oder /fast beim Betrachten eines Sub-Agenten stillschweigend den Modell-Picker des Lead öffnete; v2.1.199 zeigt einen Hinweis, der erklärt, dass der Befehl für den Lead gilt, und derselbe Fix verhindert, dass der Modell-Picker im falschen Kontext geöffnet wird. Die Sitzungs-Zeilen von claude agents erhalten ebenfalls einen kosmetischen Fix: Pull-Request-Links werden nun als bloßes #N ohne das redundante „PR"-Label angezeigt.
Retry-Richtlinie, Watchdog und transiente 429
Die für den Nutzer sichtbarste Verhaltensänderung in v2.1.199 ist die Retry-Richtlinie. Die Version erhöht die standardmäßige Anzahl der Retries für transiente Nicht-Kapazitäts-Fehler (429, die nicht mit dem Nutzungslimit des Nutzers zusammenhängen, 500-Klasse Server-Fehler, 529 Overloaded) von einem kleinen festen Wert auf 300, mit Backoff. Die Version hebt außerdem die frühere Deckelung von 15 auf die Umgebungsvariable CLAUDE_CODE_MAX_RETRIES auf, sodass Nutzer und CI-Skripte einen höheren Wert setzen können, ohne dass er stillschweigend begrenzt wird. Die Änderung ist gezielt: Kapazitäts-bezogene Fehler (das eigene Ratenlimit des Nutzers, das Pro/Max-Nutzungslimit) sind nicht betroffen, und Abonnenten erhalten automatische Retries, während eine Sitzung an einem Nutzungslimit dieses weiterhin wie zuvor meldet. Die Umgebungsvariable CLAUDE_CODE_RETRY_WATCHDOG, die die gesamte Wiederholungszeit pro Turn begrenzt, bleibt unverändert, sodass eine aus dem Ruder laufende Retry-Schleife weiterhin vom Watchdog abgefangen wird.
Der Fix ist mit dem v2.1.198-Netzwerkabbruch-Retry gepaart (transiente Fehler wie ECONNRESET werden nun mit Backoff wiederholt, statt den Turn abzubrechen), und beide verwandeln gemeinsam den Fehlermodus „transienter Netzwerk-Hänger bricht eine lange Generierung ab" in „transienter Hänger wird wiederholt, die Teilantwort bleibt erhalten, wenn die Retries erschöpft sind, die Deckelung wird weiterhin respektiert". Für CI-Workflows, die Claude Code gegen eine Flotte von Repositories laufen lassen, ist die Änderung eine strikte Verbesserung: eine lange Generierung, die in Minute 8 eines 10-Minuten-Laufs einen 529 trifft, muss nicht mehr von vorne gestartet werden.
Kleinere Fixes, die es wert sind, erwähnt zu werden
Die Versionshinweise zu v2.1.199 schließen einen langen Schwanz kleinerer Fixes ab. Die Fortschrittsanzeigen von Hintergrund-Jobs hängen nicht mehr minutenlang, während der Job lange Kommandos ausführt. Hintergrund-Sitzungen auf speicherarmen Maschinen zeigen nun eine geringe Speichermenge an und schlagen vor, Ressourcen freizugeben, statt einen generischen Fehler anzuzeigen. Remote-Sitzungen flappen nicht mehr zwischen Working und Idle in der Agenten-Ansicht, wenn ein Hintergrund-Agent fertig wird. claude stop wird nicht mehr stillschweigend durch einen konkurrierenden Hintergrund-Agenten-Respawn rückgängig gemacht; der Respawn respektiert nun den Stop. Das Öffnen oder Fortsetzen einer Sitzung ohne neue Nachrichten vergrößert die Transkript-Datei nicht mehr. Das In-den-Hintergrund-Schalten einer Sitzung mit ← oder /background lässt ihr /color nicht mehr aus der Zeile der Agenten-Ansicht verschwinden. Das Zurücksetzen einer korrumpierten Konfigurationsdatei aus dem Wiederherstellungs-Dialog beim Start zerstört die Datei nicht mehr unrettbar; sie wird nun zuerst gesichert. claude --dangerously-skip-permissions daemon <subcommand> wird nicht mehr als Chat-Prompt behandelt; das Subkommando wird nun ausgeführt. Claude in Chrome öffnet nicht mehr wiederholt die Wiederverbindungs-Seite, wenn Sitzungen aus unterschiedlichen Builds oder Konfigurations-Verzeichnissen laufen.
Warum das für Claude-Code-Nutzer wichtig ist
v2.1.199 ist die dritte aufeinanderfolgende Claude-Code-Version in dieser Woche, und die dritte aufeinanderfolgende Version, die dieselbe Fläche härtet: den Hintergrund-Agenten- und Sub-Agenten-Workflow, den v2.1.198 zum Standard für Code-Aufgaben in einem Worktree gemacht hat, aufbauend auf dem Sonnet-5-Standard, den v2.1.197 zwei Tage zuvor eingeführt hat. Das Muster ist konsistent: das Modell ist stabilisiert, der Auto-PR-Flow ist stabilisiert, und die Arbeit konzentriert sich auf die Fehlermodi, die der Auto-PR-Flow in der Produktion sichtbar macht. Die Crash-Schleife des Hintergrund-Agenten-Daemon unter Linux, der Streaming-Response-Verlust-Bug, die stillen Sub-Agenten-Fehler, die SSL-Fehlerbehandlung hinter Unternehmens-Proxies und die Plan-Mode-Asymmetrie sind genau die Art von Problemen, die erst dann auftreten, wenn der Workflow unbeaufsichtigt in einer CI-Pipeline oder in einem langlebigen dashboard-gestützten Worktree läuft, nicht in der interaktiven Einsitz-Verwendung, die das erste Jahr von Claude Code dominierte.
Für Claude-Code-Nutzer ist der praktische takeaway ein ruhigeres claude update-Fenster an einem Freitagmorgen. Die Version ist additiv; bestehende Einsitz-Workflows sind unverändert. Das einzige neue Feature (gestapelte Slash-Skill-Aufrufe) ist eine strikte Obermenge des vorherigen Verhaltens. Die Retry-Richtlinie ist ein Standard, der mit der bestehenden Umgebungsvariable CLAUDE_CODE_MAX_RETRIES zurückgenommen werden kann. Und die Fehlermodus-Fixes (Sub-Agenten-Fehler, Erhaltung von Streaming-Antworten, Plan-Mode-Asymmetrie) sind die Art von Änderung, die ein aktiver Claude-Code-Nutzer erst bemerkt, wenn sie nicht ausgelöst werden, was der Punkt ist.
