Inhaltsverzeichnis

Sie haben in Claude Code gearbeitet, als plötzlich dieser Fehler auftauchte und die Sitzung komplett aufhörte zu reagieren?

API Error: 400 messages.3.content.40: `thinking` or
`redacted_thinking` blocks in the latest assistant message
cannot be modified. These blocks must remain as they were
in the original response.

Das Üble daran: sobald er auftaucht, löst jede weitere Eingabe denselben Fehler aus. Sie tippen, drücken Enter, derselbe 400. Die Sitzung gerät in einen "festgefahrenen" Zustand. Es handelt sich um einen bekannten Bug mit mehreren offenen Issues im offiziellen Repository von Anthropic (#10199, #12225, #13012, #22278, #63147 und weitere).

Gleich vorweg: die Ursache ist "die Beschädigung der Extended-Thinking-Blöcke beim erneuten Senden des Gesprächsverlaufs". Thinking-Blöcke tragen eine kryptografische signature, und die API validiert die signature byteweise gegen den Inhalt. Wenn Claude Code den Verlauf mit einem Bug neu aufbaut — etwa indem es den Thinking-Text leert, die signature aber behält — passt die signature nicht mehr und die API weist die Anfrage ab. Der schnellste Ausweg ist "zweimal Esc drücken und mit /rewind zu einem Checkpoint zurückkehren", oder eine neue Sitzung zu starten. Dieser Artikel behandelt den Mechanismus, die 5 Grundursachen, 3 Lösungen auf Nutzerseite, Gegenmaßnahmen für Entwickler und die Vorbeugung von Wiederholungen.

CLAUDE CODE · 400-FEHLER

Das Gesamtbild des Thinking-Block-Fehlers

— Wenn die "signature" nicht passt, weist die API das gesamte Gespräch ab

SYMPTOM
Sitzung festgefahren
Jede Eingabe wiederholt denselben 400
URSACHE
Signatur stimmt nicht
Leerer Text + übrig gebliebene signature
SCHNELLSTER AUSWEG
Esc×2 → /rewind
Zurückrollen vor die Beschädigung

Ein bekannter Bug mit mehreren Issues im offiziellen Repo von Anthropic.
Der Kern: die strenge Regel der API, dass "Thinking-Blöcke exakt so bleiben müssen wie in der ursprünglichen Antwort".

1. Was diese Fehlermeldung wirklich sagt

Im Klartext sagt die Meldung: "Die thinking- oder redacted_thinking-Blöcke in der letzten Assistant-Nachricht können nicht verändert werden. Diese Blöcke müssen so bleiben, wie sie in der ursprünglichen Antwort waren."

Anders gesagt teilt Ihnen die API mit: "Der 'Thinking-Block' im Gesprächsverlauf, den Sie (der Client) mir geschickt haben, unterscheidet sich von dem, was ich letztes Mal zurückgegeben habe. Er wurde verändert. Deshalb akzeptiere ich ihn nicht." Die Claude-API geht davon aus, dass Sie in mehrstufigen Gesprächen "die vorherige Antwort in den Verlauf aufnehmen und unverändert zurücksenden" — und gerade der Thinking-Block unterliegt der strengen Auflage, "kein einziges Zeichen zu ändern". messages.3.content.40 ist eine Positionsangabe: "der 41. Inhaltsblock der 4. Nachricht" ist die Stelle des Problems.

Der wichtige Punkt: in den meisten Fällen ist dies KEIN Fehler in Ihrem Code oder Prompt. Die Hauptursache ist ein Bug in der Art, wie Claude Code den Gesprächsverlauf (das Session-JSONL) neu aufbaut und dabei die Thinking-Blöcke beschädigt. Sie müssen sich also nicht den Kopf zerbrechen, ob "ich es falsch benutze" — es ist ein bekannter Bug mit Workarounds.

2. Hintergrund: Extended Thinking und der "Signatur"-Mechanismus

Warum ist allein der Thinking-Block so streng? Der Grund liegt in der Funktionsweise von Extended Thinking.

Wenn Claude mit aktiviertem Extended Thinking antwortet, erzeugt es vor der Antwort einen "Thinking-Block". Das ist Claudes Zwischenüberlegung — das interne "Wie es gedacht hat", das die Qualität der finalen Antwort steigert. Diesem Block wird eine kryptografische signature zugewiesen — eine Art digitale Unterschrift, die garantiert, dass "dieser Denkinhalt tatsächlich von Claude erzeugt und nicht verändert wurde".

In mehrstufigen Gesprächen und Tool-Use-Schleifen wird jedes Mal der gesamte vorherige Austausch an die API zurückgesendet. Die Thinking-Blöcke müssen ebenfalls gesendet werden, aber die signature wird über den "gesamten ursprünglichen Thinking-Text" berechnet — ändert sich der Text also auch nur um ein Zeichen, schlägt die Signaturvalidierung fehl. Aus Sicherheitsgründen weist die API Thinking-Blöcke zurück, deren signature nicht passt. Das ist der Kern des 400-Fehlers.

Warum es die signature gibt

Das Verhindern der Veränderung von Thinking-Blöcken blockiert prompt injection und das Fälschen von Gedanken. Es ist ein Sicherheitsmechanismus, der die Tatsache schützt, dass "Claude dies wirklich gedacht hat" — die Strenge hat einen Grund.

3. Warum es passiert — 5 Grundursachen

Die konkreten Szenarien für eine nicht passende signature lassen sich in fünf einteilen — synthetisiert aus den offiziellen Issues von Anthropic und Berichten aus der Community.

5 GRUNDURSACHEN

Fünf Grundursachen für eine nicht passende signature

URSACHE 1 · Bug bei der Sitzungswiederaufnahme (am häufigsten)
Claude Code leert den Thinking-Text auf "", behält aber die signature. Bei der Wiederaufnahme sendet es "leerer Text + ursprüngliche signature" und scheitert an der Validierung. Der klassische Issue #63147.
URSACHE 2 · Verschachtelung beim Streaming
In langen Sitzungen verschachteln sich parallele oder schnell aufeinanderfolgende API-Antworten im JSONL. Fragmente verschiedener Nachrichten vermischen sich und die Blockreihenfolge bricht zusammen.
URSACHE 3 · Reparaturlogik läuft Amok
Der interne Verlaufsreparatur-Prozess von Claude Code ordnet Thinking-Blöcke um oder verändert sie. Eine gut gemeinte Reparatur zerstört am Ende die signature.
URSACHE 4 · Drittanbieter-Proxy/SDK
Relay-Proxys (CLIProxyAPI usw.) serialisieren Nachrichten neu und verändern das thinking. Die Hauptursache für "Invalid signature"-Fehler.
URSACHE 5 · Verlaufsänderung in der eigenen App
In Apps, die die API/SDK selbst aufrufen, das Löschen, Zusammenfassen oder Umformatieren von Thinking-Blöcken mitten in einer Tool-Use-Schleife vor dem Zurücksenden. Der häufigste Fehler bei Eigenimplementierungen.

Der rote Faden: weicht ein Thinking-Block auch nur um ein Byte vom Original ab, gibt es immer einen 400.
Die Ursachen 1 bis 4 sind Bugs von Claude Code / des Proxys; Ursache 5 ist ein Problem der Eigenimplementierung.

4. Drei Soforthilfen (für Claude-Code-Nutzer)

Wenn Ihre Sitzung festgefahren ist, probieren Sie drei Methoden in der Reihenfolge der Wiederherstellungsgeschwindigkeit.

3 LÖSUNGEN

Drei Lösungen nach Wiederherstellungsgeschwindigkeit

LÖSUNG 1 · /rewind (höchste Priorität)
Drücken Sie zweimal Esc, oder führen Sie /rewind aus. Gehen Sie zurück zum Checkpoint vor dem beschädigten Zug. Der beste Zug — stellt wieder her und bewahrt dabei den Kontext.
LÖSUNG 2 · Neue Sitzung
/clear oder starten Sie eine frische Sitzung. Am zuverlässigsten, verliert aber den Kontext. Notieren/committen Sie zuvor wichtige Arbeit.
LÖSUNG 3 · JSONL-Reparatur
Entfernen Sie alle Thinking-Blöcke aus dem Session-JSONL. Ein Community-Tool (siehe unten) entfernt nur das thinking und behält den Gesprächsverlauf. Ein fortgeschrittener Zug, der den Kontext bewahrt.

Probieren Sie zuerst LÖSUNG 1 (Esc×2 / rewind). Schlägt sie fehl, LÖSUNG 2. Müssen Sie den Kontext behalten, LÖSUNG 3.
Und aktualisieren Sie Claude Code stets auf die neueste Version (Anthropic behebt dies schrittweise).

Hinweis zu LÖSUNG 3: die Community hat ein "Claude Code thinking blocks fix"-Tool veröffentlicht (z. B. miteshashar/claude-code-thinking-blocks-fix auf GitHub). Es entfernt alle Thinking-Inhaltsblöcke aus dem Session-JSONL und beseitigt so das Signaturproblem, während der Gesprächsverlauf erhalten bleibt. Es lohnt sich, wenn Sie häufig darauf stoßen oder lange Sitzungen intensiv nutzen. Aber es ist ein inoffizielles Tool, also auf eigene Gefahr verwenden — sichern Sie das JSONL, bevor Sie es ausführen.

Die wichtigste dauerhafte Behebung ist, "Claude Code auf der neuesten Version zu halten". Führen Sie claude update aus oder folgen Sie den offiziellen Update-Schritten. Anthropic rollt für diese Bug-Serie (#10199, #12225, #63147 usw.) schrittweise einen "defensiven Schutzmechanismus aus, der Thinking-Blöcke mit leerem Text plus signature erkennt und sie vor dem Senden entfernt". Ältere Versionen stoßen häufiger darauf.

5. Für Entwickler: das Problem in der eigenen App vermeiden (API/SDK)

Wenn Sie selbst eine App bauen, die die Claude-API/SDK aufruft (Extended Thinking + Tool Use), werden Sie in Ihrer eigenen Implementierung auf denselben Fehler stoßen. Drei Prinzipien verhindern ihn.

// BAD: deleting/altering thinking blocks before sending back
const history = previousMessages.map(m => ({
  ...m,
  content: m.content.filter(b => b.type !== 'thinking') // mismatches signature
}));

// GOOD pattern 1: keep thinking blocks "exactly as-is"
// Push the assistant message from the API into history untouched
messages.push(assistantMessageFromApi); // keep the signature intact

// GOOD pattern 2: "fully drop" thinking from past turns
// Don't send empty text + signature; omit the block entirely
const clean = previousMessages.map(m => {
  if (m.role !== 'assistant') return m;
  return {
    ...m,
    content: m.content.filter(b =>
      b.type !== 'thinking' && b.type !== 'redacted_thinking'
    ),
  };
});
// NOTE: do NOT drop them from the "latest" assistant message (during tool use)

Die drei Prinzipien: ① Bewahren Sie den signierten Thinking-Text vollständig und lassen Sie ihn unversehrt hin- und herwandern. ② Wenn Sie das thinking vergangener Züge nicht senden, entfernen Sie den gesamten Block (leerer Text plus signature ist der schlimmste Fall). ③ Fügen Sie beim Aufbau der Anfrage einen defensiven Schutzmechanismus hinzu, der Thinking-Blöcke "mit leerem Text, aber mit signature" erkennt und entfernt.

Die eiserne Regel für Tool-Use-Schleifen

In Extended-Thinking- + Tool-Use-Schleifen (tool_use → tool_result) verändern Sie niemals den Thinking-Block der "letzten" Assistant-Nachricht. Die nächste Anfrage, die tool_result zurückgibt, muss das vorangehende thinking + tool_use exakt unverändert enthalten. Wenn Sie das Claude Agent SDK oder das Vercel AI SDK verwenden, prüfen Sie, ob die Bibliothek dies korrekt handhabt.

6. Abgrenzung von ähnlichen Fehlern

Es gibt mehrere thinking-bezogene 400-Fehler, die leicht zu verwechseln sind. Grenzen wir die drei wichtigsten ab.

FehlermeldungBedeutungHauptlösung
thinking blocks ... cannot be modifiedDas Thema dieses Artikels. Signatur und Inhalt stimmen nicht überein/rewind, neue Sitzung, Update auf die neueste Version
Invalid signature in thinking blockDie signature selbst ist ungültig (oft eine Veränderung durch den Proxy)Proxy-Konfiguration prüfen, direkt mit der API verbinden
The final block in an assistant message cannot be thinkingDie Assistant-Nachricht endet mit thinking (am Ende braucht es text oder tool_use)Nachrichtenstruktur korrigieren, SDK aktualisieren

Die gemeinsame Grundursache ist, dass "Extended-Thinking-Blöcke nicht korrekt gehandhabt werden". Für Claude-Code-Nutzer lösen sich die meisten Fälle mit /rewind + Update auf die neueste Version. Bei Eigen-Apps müssen Sie die Nachrichtenstruktur und die Bibliotheksimplementierung überprüfen. Wenn Sie über einen Proxy gehen (CLIProxyAPI, diverse Gateways), verdächtigen Sie zuerst, dass der Proxy das thinking verändert.

7. Checkliste zur Vorbeugung von Wiederholungen

Eine praktische Checkliste, um häufige Wiederholungen zu vermeiden.

Claude-Code-Nutzer: ① Halten Sie es mit claude update auf der neuesten Version (die größte Vorbeugung). ② Setzen Sie sehr lange Sitzungen regelmäßig mit /clear zurück (verringert das Verschachtelungsrisiko). ③ Committen Sie häufig in git für wichtige Arbeit (auch im festgefahrenen Zustand wiederherstellbar). ④ Erwägen Sie ein JSONL-Reparatur-Tool, wenn es häufig wiederkehrt. ⑤ Melden Sie Reproduktionen in den offiziellen Issues von Anthropic (beschleunigt die Behebung).

API/SDK-Entwickler: ① Fügen Sie Assistant-Nachrichten ohne Veränderung der API-Antwort in den Verlauf ein. ② Wenn Sie vergangenes thinking verwerfen, entfernen Sie den gesamten Block (kein leerer Text plus signature). ③ Fügen Sie beim Aufbau der Anfrage einen defensiven Schutzmechanismus hinzu (leeren Text plus signature erkennen → entfernen). ④ Verwenden Sie das neueste offizielle SDK und minimieren Sie eigenes Umformen von Nachrichten. ⑤ Wenn Sie hinter einem Proxy sind, prüfen Sie die Thinking-Transparenz.

Fazit

Der 400-Fehler "thinking blocks ... cannot be modified" von Claude Code tritt auf, wenn Extended-Thinking-Blöcke beim erneuten Senden des Verlaufs beschädigt werden und die kryptografische signature nicht mehr zum Inhalt passt. Es ist ein bekannter Bug mit mehreren Issues im offiziellen Repo von Anthropic, und in den meisten Fällen ist es nicht Ihre Schuld. Die fünf Ursachen: Bug bei der Sitzungswiederaufnahme (am häufigsten), Verschachtelung beim Streaming, Amok laufende Reparaturlogik, Drittanbieter-Proxys und Verlaufsänderung in der eigenen App.

Für Claude-Code-Nutzer ist die schnellste Wiederherstellung ① Esc×2 / /rewind zurück zu einem Checkpoint; schlägt das fehl, ② eine neue Sitzung (/clear); zum Bewahren des Kontexts ③ ein JSONL-Reparatur-Tool. Die wichtigste dauerhafte Behebung ist, "Claude Code auf die neueste Version zu aktualisieren" — Anthropic rollt schrittweise einen defensiven Schutzmechanismus aus. API/SDK-Entwickler sollten die drei Prinzipien befolgen: Thinking-Blöcke unverändert hin- und herwandern lassen / sie vollständig entfernen, wenn man sie verwirft / einen defensiven Schutzmechanismus hinzufügen.

Ebenfalls lesenswert: Was ist das Claude Agent SDK, vollständiger Leitfaden zum Vercel AI SDK, Was ist Cursor, Deploy-Workflow mit Claude Code/Cursor.

FAQ

Q. Ist dieser Fehler ein Fehler in meinem Prompt oder Code?
A. In den meisten Fällen nein. Wenn er während der Nutzung von Claude Code auftaucht, ist es fast sicher ein bekannter Bug auf der Claude-Code-Seite (ein Defekt beim Neuaufbau des Sitzungsverlaufs). Mehrere Issues sind im offiziellen Repo von Anthropic offen und Korrekturen sind in Arbeit. Sie müssen sich keine Vorwürfe machen. Nur bei Eigen-Apps (die die API direkt aufrufen) müssen Sie Ihre Implementierung überprüfen.

Q. /rewind behebt es nicht. Was nun?
A. Eine neue Sitzung starten (/clear) ist am zuverlässigsten. Sie verlieren den Kontext, entkommen aber sicher dem festgefahrenen Zustand. Legen Sie wichtige Arbeit zuvor per git commit oder Notizen beiseite. Kehrt es wieder, aktualisieren Sie Claude Code auf die neueste Version; bleibt es bestehen, erwägen Sie ein JSONL-Reparatur-Tool.

Q. Kann ich es vermeiden, indem ich Extended Thinking abschalte?
A. Technisch ja, aber Extended Thinking verbessert die Genauigkeit bei komplexen Aufgaben erheblich, daher ist das Abschalten nicht zu empfehlen. Gehen Sie das Problem zuerst mit Update auf die neueste Version + /rewind an und erwägen Sie dies nur als letzten Ausweg in besonderen Umgebungen (etwa hinter einem Proxy), in denen es weiterhin wiederkehrt.

Q. Ist das JSONL-Reparatur-Tool sicher?
A. Es ist inoffiziell, also auf eigene Gefahr verwenden. Sichern Sie immer das Session-JSONL, bevor Sie es nutzen. Der Mechanismus lautet "alle Thinking-Inhaltsblöcke entfernen und den Gesprächsverlauf behalten", was im Prinzip sicher ist — aber die offizielle Behebung (Update auf die neueste Version) bleibt die eigentliche Lösung.

Q. In meiner eigenen App löst die Kombination aus Tool Use und thinking diesen Fehler aus.
A. Die Ursache ist, dass "Sie den Thinking-Block der letzten Assistant-Nachricht verändern". Die nächste Anfrage, die tool_result zurückgibt, muss die vorangehenden thinking- + tool_use-Blöcke exakt so enthalten, wie die API sie zurückgegeben hat (mit signature). Wenn Sie das thinking vergangener Züge verwerfen, entfernen Sie den gesamten Block (kein leerer Text plus signature). Das neueste offizielle SDK übernimmt den Großteil davon automatisch.