Cline v4.0.1, veröffentlicht am 28. Juni 2026, ist eines der ungewöhnlicheren stabilen Releases der jüngeren KI-Tooling-Geschichte. Die Versionshinweise bestehen aus einer einzigen Zeile: „Roll the stable VS Code extension back to the pre-SDK-migration codebase to resolve regressions reported in 4.0.0. This release ships the 3.89.2 extension code under a higher version number so existing 4.0.0 users receive the update. SDK-migration work continues separately on main.“ Achtundvierzig Stunden zuvor hatte Cline v4.0.0 die VS Code-Erweiterung auf das gemeinsame Cline SDK migriert, die zentrale Architekturänderung, die im Cline-4.0-Artikel vom 27. Juni behandelt wurde. v4.0.2, veröffentlicht am 29. Juni (dem Tag, an dem dieser Artikel erscheint), bringt den SDK-basierten Codepfad mit Reasoning-Effort-Unterstützung für DeepSeek-Thinking-Modelle, einer zentralisierten ClinePass-Reasoning-Schicht und einer Reihe von Anbieter- und Webview-Fixes zurück. Die 72-Stunden-Sequenz ist ein durchgearbeitetes Beispiel dafür, wie eine große Migration wiederhergestellt werden kann, ohne die Arbeit selbst rückgängig zu machen.
Was der Rollback tatsächlich ausgeliefert hat
Die SDK-Migration in 4.0.0 war seit Monaten in Arbeit; die Vergleichsansicht zwischen v3.89.2 und v4.0.0 zeigt, dass die gesamte Erweiterung von ihrer npm-basierten Legacy-Task-Implementierung auf eine gemeinsame TypeScript-Runtime umgezogen ist, die auch die Cline-CLI, Kanban und das JetBrains-Plugin antreibt. Innerhalb weniger Stunden nach dem stabilen Release beschrieben zwei GitHub-Issues Regressionen, die bestehende 3.x-Nutzer nicht gesehen hatten. Issue #11934, eröffnet am Morgen nach dem 4.0.0-Release, meldete: „all file-change reviews stopped showing diffs in VS Code. Instead of displaying the usual side-by-side or inline diff, Cline only presented Approve or Reject buttons with no diff view at all in the editor window.“ Issue #11907, eröffnet spät am 27. Juni, meldete run_commands-Fehler während Dateibearbeitungen mit lokalen Qwen-Modellen. Beide Melder stellten fest, dass die Rückkehr zu 3.89.2 das normale Verhalten sofort wiederherstellte.
Die Folgekommentare auf #11907 haben die Entscheidung zum Rollback geprägt. Ein Kommentator, der GLM 5.2 und MiniMax M3 über Ollama nutzte, schrieb, dass Cline nach dem 4.0-Update „basically unusable“ geworden sei, weil „file editing no longer works reliably at all: the VS Code diff preview is gone or not shown properly, edits are not applied, and the new CLI/tool-based flow fails with these models.“ Der Kommentar verwies auf Commit #11801 als wahrscheinlichen Übeltäter und schlug einen manuellen Patch der gebündelten @cline/core-Distribution vor. Das ist die Art von Meldung, die ein Projekt nicht für jeden Nutzer einzeln triageen will. Die Lösung war strukturell: Die Legacy-Erweiterung vorrollen und die SDK-Arbeit auf main lassen.
Der legacy-extension-Branch und ein dedizierter Veröffentlichungs-Workflow
Der Mechanismus ist der interessante Teil. Cline hat auf main keinen einzigen Commit rückgängig gemacht; die SDK-Migrationsarbeit lief unverändert weiter. Stattdessen hat das Projekt einen separaten legacy-extension-Branch angelegt, der die npm-basierte 3.89.x-Codebasis enthält, sowie einen neuen ext-vscode-publish-legacy.yml-Workflow, der aus diesem Branch veröffentlicht. Der Workflow-Kommentar erklärt die Designentscheidung:
Publishes the legacy (pre-SDK-migration) VS Code extension from the
legacy-extensionbranch. This branch holds the npm-based 3.89.x codebase, rolled forward under a 4.0.x version so existing 4.0.0 users still receive the update. The mainext-vscode-publish-stable.ymlworkflow (bun-based) stays the path for releasingmainonce the SDK migration is solid.
Der Workflow bindet auch die eigene npm-basierte Testsuite der Legacy-Erweiterung ein, statt die geteilte .github/workflows/ext-vscode-test.yml wiederzuverwenden, weil diese Suite auf main Bun-basiert ist und den falschen Branch testen würde. Der Legacy-Workflow checkt den legacy-extension-Branch aus, führt npm --prefix apps/vscode ci aus, danach npm run ci:check-all, npm run ci:build, die Unit-Tests, die Erweiterungs-Integrationstests und die Webview-Tests. Das Release-Tag wird aus der Paketversion im Legacy-Branch abgeleitet, das Changelog muss mit der neuen Versionsüberschrift beginnen, und das Tag wird nur erstellt, wenn es auf origin noch nicht existiert. Das ist die Produktionsform einer „Wir müssen den alten Code vorrollen, während wir den neuen Code fixen“-Wiederherstellung.
Die Vergleichsansicht zwischen v4.0.0 und v4.0.1 ist entsprechend kurz: ein einziger chore(vscode): bump to 4.0.1 for legacy rollback release-Commit, plus die CHANGELOG.md- und apps/vscode/package.json-Bumps. Der Rest liegt auf dem legacy-extension-Branch. Dasselbe Muster erklärt, warum ein 4.0.1-Tag die 3.89.2-Codebasis ausliefern kann: Die Version wird vorgespult, der Legacy-Branch ist die Quelle der Wahrheit, und die SDK-Migration bleibt auf main für die eventuelle stabile Rückkehr intakt.
Was v4.0.2 zurückgebracht hat
v4.0.2, veröffentlicht am Morgen des 29. Juni, bringt den SDK-basierten Codepfad mit acht Fix- und Feature-Commits auf den Legacy-Branch zurück. Die Vergleichsansicht zwischen v4.0.1 und v4.0.2 ist das eigentliche Signal dafür, dass die SDK-Migration stabilisiert wird, statt aufgegeben zu werden.
Das Hauptfeature ist die Reasoning-Effort-Unterstützung inklusive xhigh für DeepSeek-Thinking-Modelle (#11938). Der PR fügt einen Reasoning-Effort-Selektor hinzu, der auf Thinking-fähige Modelle beschränkt ist, sowie einen Fix, der none nicht an die Provider-API weiterleitet, damit das Modell selbst, nicht der Provider-Wrapper, entscheidet, wann es die Reasoning-Ausgabe überspringt. Ein Folge-PR (#11954) zentralisiert die Reasoning-Effort-Unterstützungsschicht, damit dieselbe Komponente das Setting zwischen ClinePass und direkten Anbietern verwaltet, mit einem Fix, der die Reasoning-Effort-Steuerung für ClinePass-Modelle freischaltet und das Include-Flag für Claudes Budget-Reasoning normalisiert.
Drei weitere Commits ziehen die Anbieterfläche von ClinePass und Z.ai enger. #11950 verbessert die ClinePass-Anbieter-UX mit einem Zwischenschritt vor der Modellauswahl und einem Fallback-Pfad für ClinePass-Aktionen. #11951 bevorzugt kanonische Z.ai-Modell-IDs und entfernt redundante Alias-Filterung auf der Cline-Seite. #11958 poliert die ClinePass- und Z.ai-Metadaten. #11955 behebt die Webview-Umgebungsvariablen-Ersetzung, die in der SDK-basierten Erweiterung stillschweigend kaputtgegangen war. #11960 setzt die Focus-Chain-Standardeinstellungen im Webview-State so, dass der Toggle beim Laden den korrekten Wert widerspiegelt.
Der Release-Commit chore(vscode): bump to 4.0.2 for legacy release ist dieselbe Art Versionssprung wie bei 4.0.1, aber der Diff in der Vergleichsansicht macht klar, dass 4.0.2 kein reiner Rollback mehr ist; es ist der SDK-Codepfad, der mit einer Reihe von Fixes, die das Projekt gesammelt hat, während die stabile Erweiterung auf 3.89.x lief, auf den Legacy-Branch zurückkehrt.
CLI v3.0.32 landet am selben Tag auf SDK v0.0.54
Die CLI-Linie wurde während des gesamten Erweiterungs-Rollbacks weiterhin auf dem gemeinsamen SDK ausgeliefert, und CLI v3.0.32 erschien am selben Morgen wie v4.0.2 auf SDK v0.0.54. Die CLI-Versionshinweise listen fünf Änderungen: einen Zwischenschritt vor der ClinePass-Modellauswahl, einen auswählbaren ClinePass-Abonnement-Bildschirm, die Hervorhebung von ClinePass in der Startmeldung, die konsistente Verwendung von „ClinePass“ als ein Wort in der CLI-UI sowie genauere Kontextverdichtung und klarere Fehlermeldungen aus SDK v0.0.54. Der SDK-seitige Verdichtungs-Fix (#11894, am Vortag) war eine grundlegende Token-Budgeting-Verbesserung, die an die CLI ausgeliefert wurde, ohne auf die Stabilisierung des Erweiterungs-Rollbacks zu warten.
Die Aufteilung ist aufschlussreich. CLI, Kanban und JetBrains-Plugin wurden nie zurückgerollt, weil die SDK-Migrations-Regressionen auf der CLI-Oberfläche anders und weniger gravierend waren als die Regressionen bei Dateibearbeitung und Diff-Vorschau in der VS Code-Erweiterung. Der Legacy-Veröffentlichungspfad ist erweiterungsspezifisch, was darauf hindeutet, dass die Wiederherstellung durch die VS Code-Diff- und Bearbeitungs-Regressionen getrieben war, nicht durch einen allgemeineren SDK-Fehler.
Was zu beobachten ist
Drei Signale, die in der kommenden Woche zu beobachten sind. Erstens: Wenn das nächste VS Code-Erweiterungs-Release aus dem Haupt-ext-vscode-publish-stable.yml-Workflow statt aus dem Legacy-Workflow kommt, gilt die SDK-Migration als stabilisiert. Der Legacy-Workflow merkt ausdrücklich an, dass er „releasing main once the SDK migration is solid“ dient, also ist der Rückweg im Actions-Tab beobachtbar. Zweitens: Beobachten Sie, ob die Threads #11934 und #11907 durch einen 4.0.x-Fix statt durch einen manuellen Patch geschlossen werden; wenn der Acht-Commit-Stapel aus 4.0.2 sie schließt, sind die Dateibearbeitungs-Regressionen behoben. Drittens: Die SDK-Linie (@cline/sdk) ist nun öffentlich für Entwickler, die ihre eigenen Agenten bauen, und v0.0.54 war das erste SDK-Release, das parallel zu einer bekanntermaßen kaputten Erweiterung ausgeliefert wurde; wenn v0.0.55 oder v0.0.56 einen Hinweis „tested against the stable extension“ enthält, sind Erweiterungs- und SDK-Linie wieder zusammengelaufen.
Die weiter gefasste Lektion ist strukturell. Wenn eine große Migration den stabilen Pfad zerbricht, ist die billigere Option, die Migration rückgängig zu machen und neu zu beginnen; Cline hat stattdessen den Veröffentlichungspfad abgetrennt (Legacy-Branch, dedizierter Workflow, inline Testsuite) und die SDK-Arbeit auf main weiterlaufen lassen, während 3.89.x-Nutzer weiterhin Updates erhielten. Dasselbe Muster zeigte sich bei OpenAI mit der Codex-0.142-Governance-Arbeit, als der Noise-Relay 0.141 zuerst ausgeliefert wurde, um den Transport abzuhärten, und bei Vinext mit der Cloudflare/Vercel-Adapter-Arbeit, als das Framework die Adapter vor der Runtime-Konsolidierung auslieferte. Der Punkt ist, dass die Migrationsform von 2026, quer durch Astro 7 mit seinem Vite-8-Rust-Compiler, Oxc mit seinen inkrementellen Tree-Shake-Fortschritten und nun Cline mit seinem SDK-Schritt, eine Abfolge großer Architekturumschreibungen ist, die stufenweise statt in einem einzigen Big Bang ausgeliefert werden. Cline 4.0.1 ist das, was eine ehrliche „Stufe 1 der Migration“ aussieht, wenn der stabile Pfad weiter funktionieren muss.
