Inhaltsverzeichnis
- 1. Was wirklich passiert — das Token „court" und die invoke-Tags
- 2. Hintergrund: Auch ein Agent „generiert" seine Tool-Aufrufe
- 3. Warum es passiert — zwei Hauptursachen und Auslöser
- 4. Drei verbreitete Irrtümer, korrigiert
- 5. Sofort beheben (für Claude-Code-Nutzer)
- 6. Für Entwickler: über API/SDK verhindern
- 7. Abgrenzung zu ähnlichen Fehlern
- 8. Offizieller Status
- 9. Checkliste zur Vorbeugung
- Fazit
- FAQ
Wer längere Sitzungen in Claude Code gefahren hat, hat vielleicht schon erlebt, wie plötzlich eine seltsame Zeichenfolge auf den Bildschirm strömt:
court
<invoke name="Bash">
<parameter name="command">ssh host 'cp file file.bak ; sed -i ...'</parameter>
<parameter name="description">…Beschreibung des Befehls…</parameter>
</invoke>
Your tool call was malformed and could not be parsed. Please retry.Ein Tool-Aufruf (ein Befehl), der eigentlich im Hintergrund hätte laufen sollen, sickert als roher Text in den Chat — und wird nie ausgeführt. Davor steht ein bedeutungsloses Wort, court (oder call). Da liegt die Sorge nahe: „Ist mein Rechner kaputt?" oder „Habe ich etwas falsch konfiguriert?" Doch die kurze Antwort lautet: Es liegt nicht an Ihrer Umgebung und nicht an Ihrem Befehl.
Es handelt sich um eine modellseitige Störung, bei der Claude (vor allem die Familie Opus 4.8 / 4.7) die „Steuer-Tags" eines Tool-Aufrufs genau in dem Moment beschädigt, in dem es sie generiert. Anthropics offizielles Repository führt dazu zahlreiche offene Issues (#64108, #64150, #64690, #65705, #66153, #67295, #68354 und weitere). Dieser Artikel erklärt Mechanismus, Ursachen, verbreitete Irrtümer, Lösungen für Nutzer und Entwickler, die Abgrenzung zu ähnlichen Fehlern und den offiziellen Status — gestützt auf Anthropics Dokumentation und die tatsächlichen Issues. Der wichtigste Schritt gleich vorweg: Wenn court auftaucht, beißen Sie sich nicht in dieser Sitzung fest — wechseln Sie früh in eine frische Sitzung (/clear). Warum, wird weiter unten erklärt.
Was „court" + durchgesickerte invoke-Tags wirklich sind
— ein Steuer-Tag wird kaputt generiert und sickert auf den Bildschirm, statt ausgeführt zu werden
Ein kaputter Aufruf lässt sich nicht parsen und wird daher nie ausgeführt (fail-closed) — es besteht keine Gefahr, dass ein falscher Befehl läuft.
Die echten Probleme sind eine verschwendete Runde und eine „Kettenreaktion", wenn man es laufen lässt.
1. Was wirklich passiert — das Token „court" und die invoke-Tags
Die <invoke name="Bash"> und <parameter name="command">, die Sie sehen, sind „Tool-Aufruf-Markup", das Sie eigentlich nie zu Gesicht bekommen sollten. Wenn Claude einen Befehl ausführt oder eine Datei bearbeitet, generiert es diese XML-artigen, strukturierten Tags als Tokens, und Claude Code (die Harness) parst sie und führt den Befehl tatsächlich aus. Normalerweise absorbiert die Harness die Tags, sie erreichen den Bildschirm nie, und Sie sehen nur das Ergebnis des Tools.
Diesmal jedoch wurde das „öffnende Steuer-Token" des Tool-Aufrufs kaputt generiert, und das fremde Wort court oder call hat sich vorn eingeschlichen. Die Harness reagiert nur auf strikte Syntax, also entscheidet sie „das ist kein Tool-Aufruf, sondern nur Text" und streamt ihn direkt auf den Bildschirm. Der Befehl läuft nicht, und Sie erhalten „Your tool call was malformed and could not be parsed." In manchen Fällen erscheint überhaupt keine Fehlermeldung, und es bleibt einfach stumm hängen (in Issue #65705 kam die Antwort als stop_reason=end_turn zurück, ohne dass etwas auszuführen war, sodass das Gespräch festhing).
Das Wort court selbst hat keine Bedeutung. Aber es ist auch kein völlig zufälliges, einmaliges Wort — über mehrere unabhängige Berichte hinweg taucht das Leck mit unheimlicher Konstanz als court / call auf. Issue #64690 analysiert es als „ein im Vokabular benachbartes Token, das anstelle des korrekten Tags ausgewählt wird." Mit anderen Worten: court versteht man am besten als Signatur, an der Sie diesen Bug erkennen.
2. Hintergrund: Auch ein Agent „generiert" seine Tool-Aufrufe
Warum kann ein „Steuer-Tag" überhaupt brechen? Der Schlüssel liegt darin, dass ein Tool-Aufruf für einen KI-Agenten letztlich nichts anderes ist als Textgenerierung.
Wenn Sie Tools mit der Claude API nutzen, sehen Sie als Entwickler das Format JSON (einen tool_use-Block). Intern folgt das Modell jedoch einem verborgenen System-Prompt, den Anthropic automatisch einfügt, und generiert die umschließenden Tags <function_calls>, <invoke> und <parameter> als Strom von Tokens. Die API-Schicht parst diese und wandelt sie in einen sauberen tool_use-JSON-Block um (gemäß der offiziellen Tool-Use-Dokumentation). Jeder „Tool-Aufruf" in MCP und bei KI-Agenten setzt auf diesem Mechanismus auf.
Entscheidend ist hier, dass der Parser der Harness „fail-closed" arbeitet (er irrt auf der sicheren Seite). Weicht ein Tag auch nur um ein Token von der erwarteten Form ab, rät die Harness nicht und führt nichts aus — sie lehnt es sofort als fehlerhaft ab. Das ist das richtige Harness-Design: einen mehrdeutigen Befehl „hilfreich zurechtzubiegen" und auszuführen, wäre weitaus gefährlicher. Dieses ganze Phänomen ist also ein Fall von „kaputt → abgelehnt → nicht ausgeführt" — mit anderen Worten: Es ist sicher gescheitert.
In einem Satz
Ein Tool-Aufruf ist „Text mit Spezial-Tags", den das Modell generiert. Wenn das öffnende Token dieser Tags bei der Generierung bricht, kann die Harness es nicht erkennen, sodass es in den Fließtext sickert und nicht läuft. Die Ablehnung selbst ist ein korrekter Sicherheitsmechanismus; der Bug liegt rein in der modellseitigen Generierung.
3. Warum es passiert — zwei Hauptursachen und Auslöser
Fasst man die tatsächlichen Issues zusammen, teilt sich die Ursache in „(1) Beschädigung zur Generierungszeit" und die „(2) Kettenreaktion durch Selbstvergiftung", die es heikel macht.
Wie es bricht und sich dann „verkettet"
· Mehrere Tool-Aufrufe in einer Nachricht / ein Tool-Aufruf direkt nach Fließtext (#66153)
· Der Zustand direkt nach Ausführung von
/compact (#67295: tritt beim ersten Aufruf nach dem Compact wieder auf)· Background-Bash (run_in_background) oder 3+ verbundene MCP-Server (#64690)
· Absatzlange lange Tool-Argumente (#49747: eine separate Variante, bei der XML in JSON blutet)
Kernaussage: der Bruch selbst ist seltene Sampling-Schwankung. Das wirklich Heikle ist die Kette in (2) —
weshalb „sich mit Wiederholungen in derselben Sitzung festbeißen" der schlechteste Zug sein kann.
4. Drei verbreitete Irrtümer, korrigiert
Informationen zu diesem Phänomen geraten leicht durcheinander. Um richtig zu reagieren, hier drei verbreitete Irrtümer geradegerückt.
| Verbreitete Annahme | Realität |
|---|---|
| „Das Tool ist durchgedreht / hat eine Fehlfunktion" | Das Gegenteil. Der kaputte Aufruf wurde ohne Ausführung abgelehnt (fail-closed). Es besteht keine Gefahr, dass ein falscher Befehl läuft; passiert ist nur „eine verschwendete Runde + ein sichtbares Leck". Es ist sicher gescheitert. |
| „Einfach wiederholen — es heilt sich von selbst, wenn man es laufen lässt" | Nur halb richtig. Ein milder Fall erholt sich beim ersten Versuch, aber sobald der kaputte Block im Verlauf sitzt, ahmt das Modell ihn nach und verkettet sich. #65705 zeigte 14 Fehlschläge in Folge über 5+ Stunden; #66153 zeigte 30+ in einer Sitzung. Sich in derselben Sitzung festzubeißen, geht nach hinten los. |
„court bedeutet etwas / ist ein Befehl" | Es bedeutet nichts — nur Trümmer eines beschädigten Steuer-Tokens. Aber court/call kehren als Markierung wieder, also sind sie als diagnostisches Zeichen nützlich. |
Der zweite Punkt ist am wichtigsten. Vorfallberichte sagen oft „beim Wiederholen wieder erholt, also kein Problem" — doch das gilt nur für den „milden" Fall, bevor die Kette beginnt. Der Kern dieses Bugs ist, dass kein noch so häufiges Wiederholen innerhalb dieser Sitzung etwas behebt, sobald der Kettenmodus einmal eingesetzt hat.
5. Sofort beheben (für Claude-Code-Nutzer)
Die Reaktion hängt davon ab, ob es noch mild ist oder die Kette bereits begonnen hat. In der Reihenfolge der Priorität:
Reihenfolge der Priorität
court auftaucht, früh /clear oder eine neue Sitzung starten. Den vergifteten Verlauf zu kappen ist am zuverlässigsten. Vor dem Wechsel den Stand mit git commit oder einer Übergabenotiz sichern./compact tritt Berichten zufolge direkt danach wieder auf — es ist keine zuverlässige Lösung.
Die Regel: „Zweimal daneben, Sitzung aufgeben und neu starten."
Je länger man im vergifteten Verlauf mahlt, desto tiefer die Wunde. Halte die CLI aktuell (aber beachte: noch ist kein Fix ausgeliefert — Aktualisieren ist Hygiene, kein Wundermittel).
Tipp: Wer den Stand routinemäßig in git oder einer .md-Übergabenotiz sichert, kann jederzeit ohne Verlust in eine neue Sitzung wechseln. Je mehr Sie lange autonome Sitzungen fahren, desto mehr zahlt sich diese Gewohnheit aus (und sie hängt direkt mit der Verwaltung Ihres Kontextfensters zusammen).
6. Für Entwickler: über API/SDK verhindern
Wenn Sie Ihren eigenen Agenten auf der Claude API / dem SDK bauen, können Sie in Ihrer Harness die folgenden Schutzmaßnahmen ergänzen. Die in Issue #65705 vorgeschlagene Erkennungslogik ist praxistauglich.
// Den empfangenen Assistant-Turn vor der Ausführung prüfen
const text = assistantText(resp);
const looksLeaked =
/<invoke\s+name=/.test(text) ||
/function_calls/.test(text) ||
/\bcourt\s*<invoke/.test(text);
// 1) Obiges Markup vorhanden, aber KEIN strukturierter tool_use-Block → kaputter Aufruf
if (looksLeaked && !hasToolUseBlock(resp)) {
// 2) Nicht anzeigen, sondern loggen. Kaputten Block NICHT im Verlauf behalten (verhindert Selbstvergiftung)
// 3) „Gib es als strukturierten tool_use aus, nicht als Text" anstoßen und automatisch wiederholen
return retryWithNudge(messages);
}
// Unvollständigen tool_use durch Abschneiden ablehnen
if (resp.stop_reason === 'max_tokens' && lastBlock(resp)?.type === 'tool_use') {
return retryWith({ max_tokens: higher }); // nicht ausführen
}Vier Prinzipien. (1) Prüfen Sie immer stop_reason (ein end_turn ohne tatsächlich laufendes Tool = der stumme Stillstand wird erkannt). (2) Verifizieren Sie vor der Ausführung, dass der Text kein <invoke name= oder function_calls enthält; falls doch, wiederholen statt ausführen. (3) Behalten Sie den kaputten Block nicht im Gesprächsverlauf (behält man ihn, ahmt die nächste Generierung ihn nach — Selbstvergiftung / #62344). (4) Halten Sie Tool-Argumente kurz und teilen Sie lange Ausgaben auf (vermeidet die Long-Payload-Variante in #49747). Selbst wenn Sie eine offizielle Harness wie das Claude Agent SDK nutzen, lohnt es sich zu verstehen, wie sich lang laufende Schleifen verhalten.
7. Abgrenzung zu ähnlichen Fehlern
Es gibt mehrere Fehler vom Typ „das Tool läuft nicht", und sie brauchen unterschiedliche Lösungen. Unterscheiden Sie diese vier, um sie nicht zu verwechseln.
| Symptom | Was es wirklich ist | Hauptlösung |
|---|---|---|
| court / call + rohe invoke-Tags angezeigt, nicht ausgeführt | Das Thema dieses Artikels. Generierungsfehler des Steuer-Tokens + Verkettung durch Selbstvergiftung | Frische Sitzung bevorzugen (/clear); nach zweimaligem Daneben nicht mahlen |
| 400 „thinking blocks cannot be modified" blockiert die Sitzung | Ein Signatur-Mismatch beim Extended Thinking (ein anderer Bug). Ein harter API-Fehler | Siehe den eigenen Artikel (Esc×2 / rewind) |
| Die Antwort bricht mitten im Stream ab (kein verstümmeltes XML) | Ein normales Abschneiden durch Erreichen von max_tokens. Kein Fehler | max_tokens erhöhen und erneut ausführen |
| XML wird auf Bedrock, LangChain usw. nicht strukturiert | Ein Drittanbieter-Client, der Anthropics Format nicht parst (langchain-aws #521). Reproduziert sich nicht auf der offiziellen API / in Claude Code | Integrationsbibliothek / Hosting-Schicht überprüfen |
Die Unterscheidungsachse ist einfach. Sehen Sie ein „court / call-Geschnipsel + rohes XML", ist es dieser Bug. Ein 400-Signaturfehler ist der Thinking-Block-Fehler. Ein sauberer Abbruch ist nur das Ausgabelimit. Nur auf Bedrock oder via LangChain deutet auf die Integrationsschicht. Weitere verbreitete Claude-Code-Fehler finden Sie in der Fehlerübersicht.
8. Offizieller Status
Stand Juni 2026 gibt es keinen bestätigten offiziellen Fix (Changelog-Eintrag), der besagt, dass dieses Phänomen behoben wurde. Verfolgt man die Release Notes bis zum aktuellen Claude Code (der 2.1.183-Linie), gibt es keinen Eintrag, der die Beschädigung der Tool-Aufruf-Serialisierung adressiert, und viele der zugehörigen Issues bleiben offen oder werden als „duplicate / stale" geführt. Jede Lösung in diesem Artikel ist daher ein Workaround in Erwartung eines offiziellen Fixes, und Sie können nicht behaupten, „ein Update auf die neueste Version behebt es" (ein Update ist empfehlenswert, aber keine garantierte Heilung).
Allerdings ist das fail-closed-Harness-Design, „einen kaputten Aufruf abzulehnen statt ihn rateweise auszuführen", für sich genommen korrekt. Behoben werden muss die Generierungsstabilität des Modells — nicht den Parser aufzuweichen, um „es zurechtzubiegen und trotzdem auszuführen", was das ernste Risiko bärge, den falschen Befehl laufen zu lassen. Das Beste, was wir als Nutzer tun können, ist, so zu arbeiten, dass die Kette vermieden wird, und Reproduktionen mit Umgebung und Logs an die offiziellen Issues zu melden (mehr Meldungen erhöhen die Priorität und beschleunigen den Fix).
9. Checkliste zur Vorbeugung
Claude-Code-Nutzer: (1) Wenn court/call auftaucht, höchstens zweimal wiederholen; bleibt es bestehen, sofort /clear / neue Sitzung. (2) Sehr lange / mehrtägige Sitzungen vermeiden; Arbeit an Bruchstellen in git/Notizen sichern. (3) Nicht mehrere Tool-Aufrufe in eine Nachricht stopfen. (4) Daran denken, dass /compact kein Allheilmittel ist (kann direkt danach wieder auftreten). (5) Die CLI aktuell halten und Reproduktionen an die offiziellen Issues melden.
API/SDK-Entwickler: (1) Immer stop_reason prüfen. (2) <invoke name= / function_calls, die in Text sickern, erkennen und wiederholen. (3) Kaputte Aufrufe nicht im Verlauf behalten (Selbstvergiftung verhindern). (4) Tool-Argumente kurz halten; lange Ausgaben aufteilen. (5) Einen unvollständigen tool_use aus einem max_tokens-Abbruch nie ausführen — stattdessen wiederholen.
Fazit
In Claude Code ist „court / call + ein roh angezeigtes <invoke>-Tag, ohne dass das Tool ausgeführt wird" eine modellseitige Störung, bei der Claude (die Familie Opus 4.8 / 4.7) das Steuer-Token eines Tool-Aufrufs in kaputter Form generiert. Die Harness lehnt es fail-closed ab, sodass keine Gefahr besteht, dass ein falscher Befehl läuft (es ist sicher gescheitert). Das wirklich Heikle ist, dass das Modell den kaputten Block nachahmt und sich „verkettet", sobald er im Verlauf bleibt. Deshalb gilt „Wiederholen behebt es" nur, solange es mild ist, und die Regel lautet „Zweimal daneben, ab in eine frische Sitzung."
Die Ursache ist zweischichtig: (1) Generierungsfehler des Steuer-Tokens + (2) Verkettung durch Selbstvergiftung. Auslöser sind unter anderem lange / mehrtägige Sitzungen, schwerer Kontext, der Zustand nach /compact, mehrere gleichzeitige Tools, 3+ MCP-Server und lange Tool-Argumente. Da Stand Juni 2026 kein offizieller Fix ausgeliefert ist, ist jede Abhilfe ein Workaround. Nutzer sollten „eine frische Sitzung bevorzugen + den Stand häufig sichern"; Entwickler sollten „stop_reason prüfen, bei erkanntem Leck wiederholen, keinen kaputten Verlauf behalten und Argumente kürzen." Wer dazu den Thinking-Block-400-Fehler, die Claude-Code-Fehlerübersicht und MCP liest, wird gegen Tool-Aufruf-Probleme deutlich widerstandsfähiger.
FAQ
Q. Liegt das „court" oder das invoke-Tag auf meinem Bildschirm an einem Fehler in meinem Befehl oder meinen Einstellungen?
A. Nein — fast sicher nicht. Dies ist eine bekannte modellseitige Störung, bei der Claude Tool-Aufruf-Tags in kaputter Form generiert; in Anthropics offiziellem Repository sind dazu mehrere Issues eingetragen (#64108, #65705, #66153 und weitere). Es ist kein Fehler in Ihrer Umgebung, Ihrem Befehl oder Ihren Einstellungen. Behandeln Sie court/call als „Signatur" des Bugs.
Q. Könnte dabei ein falscher Befehl laufen und meinen Server oder meine Dateien beschädigen?
A. Nein. Ein kaputter Tool-Aufruf wird als „malformed" eingestuft und ohne Ausführung abgelehnt (fail-closed-Design). Es passiert nur, dass die Runde verschwendet wird und der Steuertext sichtbar wird; auf Ihre Daten oder den Serverzustand hat es keine Auswirkung. Es ist darauf ausgelegt, sicher zu scheitern.
Q. Ich habe gehört „einfach wiederholen, dann behebt es sich von selbst." Stimmt das?
A. Nur, wenn es mild ist. Beim ersten, einmaligen Auftreten bringt ein Anstoß zum „Weitermachen" es oft dazu, korrekt erneut auszugeben. Aber sobald der kaputte Block im Gesprächsverlauf bleibt, nutzt das Modell ihn als Vorlage und wiederholt dieselbe Beschädigung (Selbstvergiftung). Ab dann geht Wiederholen in derselben Sitzung nach hinten los. Scheitert es zweimal in Folge, hören Sie auf zu mahlen und wechseln Sie in eine frische Sitzung (/clear).
Q. Behebt /compact es?
A. Nicht zuverlässig. Den Kontext zu komprimieren hilft manchmal, aber in Issue #67295 trat es beim allerersten Tool-Aufruf direkt nach /compact wieder auf. Der zuverlässigste Schritt ist nicht /compact, sondern eine frische Sitzung (/clear), die den Verlauf vollständig zurücksetzt. Sichern Sie Ihren Arbeitsstand vor dem Wechsel in git oder Notizen.
Q. Behebt ein Update von Claude Code auf die neueste Version es?
A. Man kann nicht sagen, dass es das „behebt". Stand Juni 2026 gibt es keinen offiziellen Changelog-Eintrag, der einen Fix bestätigt, und viele zugehörige Issues bleiben offen oder als Duplikat. Ein Update ist als Hygiene empfehlenswert, aber kein Wundermittel. Vorerst ist der beste Ansatz, so zu arbeiten, dass die Kette vermieden wird (zweimal daneben → frische Sitzung), und Reproduktionen an die offiziellen Issues zu melden.
