Claude Code 2.1.203 bis 2.1.214: Obergrenzen sind ein Eingeständnis

Zwischen dem 7. und dem 18. Juli hat Anthropic elf Versionen von Claude Code veröffentlicht, 2.1.203 bis 2.1.214, wobei zu 2.1.213 im Changelog kein Eintrag steht. Die Liste ist lang und größtenteils Kleinarbeit. Zwei Releases fallen heraus, 2.1.212 vom 17. Juli und 2.1.214 vom 18. Juli, und sie zeigen in dieselbe Richtung: harte Obergrenzen gegen Agenten, die im Kreis laufen, und eine Reihe von Berechtigungsprüfungen, die sich umgehen ließen. Meine These: Beides sind Eingeständnisse. Runaway-Loops sind ein reales Betriebsproblem, kein theoretisches. Und die Permission-Schicht, auf die viele ihre Freigabepraxis stützen, war nachweislich löchrig.

Welche Obergrenzen sind neu?

Drei Stück, alle in 2.1.212. Erstens ein sitzungsweites Limit für WebSearch-Aufrufe, Standardwert 200, einstellbar über CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION. Die Begründung im Changelog ist wörtlich, Suchschleifen zu stoppen, die aus dem Ruder laufen. Zweitens eine Obergrenze für Sub-Agenten-Starts pro Sitzung, ebenfalls 200, über CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION veränderbar, und /clear setzt das Budget zurück. Auch hier nennt der Eintrag den Grund: Delegationsschleifen, die nicht von allein aufhören. Drittens werden MCP-Tool-Calls, die länger als zwei Minuten laufen, automatisch in den Hintergrund verschoben, damit die Sitzung bedienbar bleibt. Die Schwelle lässt sich über CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS ändern oder abschalten. Dazu kommt eine Trennung, die dasselbe Muster hat: /fork kopiert die Unterhaltung jetzt in eine eigene Hintergrund-Sitzung mit eigener Zeile in claude agents, und der Sub-Agent, den der Befehl vorher innerhalb der Sitzung startete, heißt jetzt /subtask. Ein Befehl, der zwei verschiedene Dinge tat, tut jetzt eins.

200 klingt nach viel, und für die meisten Sitzungen wird die Grenze nie greifen. Genau das ist der Punkt. Ein Limit, das im Normalbetrieb unsichtbar bleibt, existiert nicht für den Normalbetrieb. Es existiert, weil jemand Sitzungen gesehen hat, die dreistellig viele Sub-Agenten gestartet haben, ohne fertig zu werden. Passend dazu steht schon in 2.1.203 der Eintrag, Agenten seien nun weniger geneigt, ihre komplette Aufgabe an einen weiteren Sub-Agenten weiterzureichen. Erst hat man es dem Modell beigebracht, dann hat man einen Zähler eingebaut.

Warum sind die Permission-Fixes der eigentliche Punkt?

Weil sie zeigen, dass die Schicht, die im Zweifel fragen soll, an mehreren Stellen einfach nicht gefragt hat. 2.1.214 listet das ungeschönt auf. Ein Bypass der Berechtigungsprüfung betraf Befehle in Windows-PowerShell-5.1-Sitzungen. Die Bash-Prüfung schließt jetzt bei Formen von File-Descriptor-Umleitungen, die Bash anders parst als der Berechtigungsanalysator, im Zweifel zu statt auf. Befehle über 10.000 Zeichen wurden falsch beurteilt und fragen jetzt immer nach, statt automatisch zu laufen. Zsh-Variablensubskripte und -Modifikatoren in [[ ]]-Vergleichen galten als inerter Text und lösen jetzt eine Freigabe aus. Bestimmte help- und man-Aufrufe wurden automatisch erlaubt, obwohl sie unsichere Optionen, Kommandosubstitutionen oder Backslash-Pfade ausführen konnten. Berechtigungsdialoge in Remote-Sitzungen konnten weiterlaufen, bevor der lokale Bestätigungsdialog überhaupt beantwortet war. Und eine Allow-Regel wie Edit(src/**) hat Schreibzugriffe auf src/-Verzeichnisse überall im Baum automatisch genehmigt statt nur unter dem Arbeitsverzeichnis.

Den unangenehmsten Eintrag hat schon 2.1.212: Der Plan-Modus hat dateiändernde Bash-Befehle wie touch und rm ohne Berechtigungsabfrage und ohne den canUseTool-Callback des SDK ausgeführt. Der Plan-Modus ist der Modus, in dem man arbeitet, wenn man dem Agenten gerade nicht erlauben will, etwas anzufassen. Dass ausgerechnet dort Löschbefehle durchliefen, ist genau der Fall, in dem die Schutzannahme und das Verhalten am weitesten auseinanderliegen. Ähnlich gelagert in 2.1.210: Sub-Agenten mit isolation: "worktree" konnten git-verändernde Befehle gegen den Haupt-Checkout ausführen statt gegen ihr eigenes isoliertes Worktree.

Ich lese das nicht als Vorwurf. Diese Fehler zu finden und öffentlich aufzuschreiben, ist mehr, als die meisten Anbieter tun, und die Liste ist auch ein Zeichen, dass jemand systematisch danach sucht. Der nüchterne Schluss bleibt trotzdem: Eine Allowlist, die Bash-Befehle parsen muss, ist ein Parser gegen einen Parser. Bash und Zsh sind Sprachen mit Jahrzehnten an Sonderfällen. Jeder dieser sechs Einträge ist ein Sonderfall, den der Analysator anders gelesen hat als die Shell. Es werden nicht die letzten sein.

Was heißt das für den Alltag?

Erstens: Behandeln Sie Berechtigungsregeln als Bequemlichkeit, nicht als Sicherheitsgrenze. Wer einem Agenten Schaden erlauben will, tut das über die Umgebung, in der er läuft, also Container, eigenes Worktree, eingeschränkte Credentials, und nicht über eine Regelliste, die Kommandozeilen interpretiert. Prüfen Sie außerdem Ihre eigenen dir/**-Regeln, die Bedeutung hat sich in 2.1.214 geändert: Einsegmentige Allow- und Hook-Muster greifen jetzt nur noch unter dem Arbeitsverzeichnis, für beliebige Tiefe schreiben Sie **/dir/**. Deny- und Ask-Regeln behalten die alte Tiefenwirkung.

Zweitens: Setzen Sie die Obergrenzen bewusst, statt die 200 zu erben. Wenn eine Ihrer Sitzungen realistisch 20 Sub-Agenten braucht, ist 200 keine Leitplanke, sondern eine sehr späte Notbremse. Die Variablen sind da, der passende Wert ist Ihrer.

Anfang Juli hatte derselbe Hersteller seine Vertrauens-Defaults zurück Richtung Aufsicht gedreht. Diese elf Tage setzen die Linie fort, nur eine Ebene tiefer: nicht mehr, wann gefragt wird, sondern ob die Frage überhaupt zuverlässig gestellt wurde. Das ist dieselbe Beobachtung wie im Agentic Engineering: Die Fähigkeit der Agenten wächst schneller als die Mechanik, die sie prüfbar hält. Verlässlichkeit liegt nicht im Modell und auch nicht in der Regelliste, sondern in der Architektur drumherum. Die Verantwortung bleibt bei dem Menschen, der den Lauf gestartet hat.

Quellen

• Claude Code: Changelog