Cline v4.0.1, released June 28, 2026, is one of the more unusual stable releases in recent AI tooling history. Its release notes are a single line: "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." Forty-eight hours earlier, Cline v4.0.0 had migrated the VS Code extension onto the shared Cline SDK, the headline architectural change covered in the June 27 Cline 4.0 piece. v4.0.2, released June 29 (the day this article ships), brings the SDK-backed code path back with reasoning effort support for DeepSeek thinking models, a centralized ClinePass reasoning layer, and a batch of provider and webview fixes. The 72-hour sequence is a worked example of how a major migration can be recovered without reverting the work itself.
What the rollback actually shipped
The 4.0.0 SDK migration had been in the works for months; the compare view between v3.89.2 and v4.0.0 shows the entire extension moved off its npm-based legacy task implementation and onto a shared TypeScript runtime that also powers the Cline CLI, Kanban, and the JetBrains plugin. Within hours of the stable release, two GitHub issues described regressions that the existing 3.x users had not been seeing. Issue #11934, opened the morning after 4.0.0 shipped, reported that "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, opened late on June 27, reported run_commands errors during file edits on local Qwen models. Both reporters noted that reverting to 3.89.2 restored normal behavior immediately.
The follow-up comments on #11907 are what shaped the decision to roll back. One commenter using GLM 5.2 and MiniMax M3 through Ollama wrote that after the 4.0 update Cline had become "basically unusable" because "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." The comment pointed to commit #11801 as the likely culprit, and proposed a manual patch of the bundled @cline/core distribution. That is the kind of report a project does not want to triage one user at a time. The fix was structural: ship the legacy extension forward and keep the SDK work on main.
The legacy-extension branch and a dedicated publish workflow
The mechanism is the interesting part. Cline did not revert any commits on main; the SDK migration work continued in place. Instead, the project created a separate legacy-extension branch that holds the npm-based 3.89.x codebase, and a new ext-vscode-publish-legacy.yml workflow that ships from that branch. The workflow comment explains the design:
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.
The workflow also inlines the legacy extension's own npm-based test suite rather than reusing the shared .github/workflows/ext-vscode-test.yml, because that suite on main is bun-based and would test the wrong branch. The legacy workflow checks out the legacy-extension branch, runs npm --prefix apps/vscode ci, then runs npm run ci:check-all, npm run ci:build, the unit tests, the extension integration tests, and the webview tests. The release tag is derived from the package version on the legacy branch, the changelog must start with the new release heading, and the tag is only created if it does not already exist on origin. This is the production shape of a "we need to ship the old code forward while we fix the new code" recovery.
The compare view between v4.0.0 and v4.0.1 is accordingly short: a single chore(vscode): bump to 4.0.1 for legacy rollback release commit, plus the CHANGELOG.md and apps/vscode/package.json bumps. Everything else is on the legacy-extension branch. The same pattern is why a 4.0.1 tag can ship the 3.89.2 codebase: the version is bumped forward, the legacy branch is the source of truth, and the SDK migration remains intact on main for the eventual stable return.
What v4.0.2 brought back
v4.0.2, released the morning of June 29, ships the SDK-backed code path back to the legacy branch with eight commits of fixes and features. The compare view between v4.0.1 and v4.0.2 is the actual signal that the SDK migration is being stabilized rather than abandoned.
The headline feature is reasoning effort support including xhigh for DeepSeek thinking models (#11938). The PR adds a reasoning effort selector scoped to thinking-capable models and a fix that does not forward none to the provider API, so the model itself, not the provider wrapper, decides when to skip reasoning output. A follow-up (#11954) centralizes the reasoning effort support layer so the same component handles the setting across ClinePass and direct providers, with a fix that surfaces reasoning effort controls for ClinePass models and normalizes Claude's budget reasoning include flag.
Three other commits tighten the ClinePass and Z.ai provider surface. #11950 improves the ClinePass provider UX with an intermediate step before model selection and a fallback path for ClinePass actions. #11951 prefers canonical Z.ai model ids and removes redundant alias filtering on the Cline side. #11958 polishes ClinePass and Z.ai model metadata. #11955 fixes webview environment variable replacement, which had silently broken template interpolation in the SDK-backed extension. #11960 defaults focus chain settings in webview state so the toggle reflects the correct value on load.
The release commit, chore(vscode): bump to 4.0.2 for legacy release, is the same kind of version bump as 4.0.1, but the diff in the compare view makes clear that 4.0.2 is no longer a pure rollback; it is the SDK code path returning to the legacy branch with a batch of fixes the project collected while the stable extension was running on 3.89.x.
CLI v3.0.32 lands on SDK v0.0.54 the same day
The CLI line continued to ship on the shared SDK throughout the extension rollback, and CLI v3.0.32 released the same morning as v4.0.2 on SDK v0.0.54. The CLI release notes list five changes: an intermediate step before ClinePass model selection, a selectable ClinePass subscription screen, promotion of ClinePass in the startup notice, consistent one-word "ClinePass" usage across the CLI UI, and more accurate context compaction and clearer error messages pulled in from SDK v0.0.54. The SDK-side compaction fix (#11894, the day before) was a basic token-budgeting improvement that shipped to the CLI without waiting on the extension rollback to settle.
The split is informative. The CLI, Kanban, and JetBrains plugin were never rolled back, because the SDK migration regressions on the CLI surface were different and less severe than the file-editing and diff-preview regressions on the VS Code extension. The legacy publish path is extension-specific, which suggests the recovery was driven by the VS Code diff and editing regressions, not a more general SDK failure.
What to watch
Three signals to monitor over the next week. First, when the next VS Code extension release ships from the main ext-vscode-publish-stable.yml workflow rather than the legacy one, the SDK migration is considered stable. The legacy workflow explicitly notes that it is for "releasing main once the SDK migration is solid," so the path back is observable in the Actions tab. Second, watch for the issues #11934 and #11907 threads to be closed by a 4.0.x fix rather than a manual patch; if 4.0.2's eight-commit batch closes them, the file-editing regressions are resolved. Third, the SDK line (@cline/sdk) is now public to developers building their own agents, and the v0.0.54 release was the first SDK release shipped alongside a known-broken extension; if v0.0.55 or v0.0.56 includes a "tested against the stable extension" note, the extension and SDK lines have re-converged.
The broader lesson is structural. When a major migration breaks the stable path, the cheaper option is to revert the migration and start over; Cline instead detached the ship path (legacy branch, dedicated workflow, inlined test suite) and let the SDK work continue on main while 3.89.x users received updates. The same pattern showed up at OpenAI with Codex 0.142's governance work when the 0.141 Noise relay shipped first to harden the transport, and at Vinext's Cloudflare/Vercel adapter work when the framework shipped adapters before shipping the runtime consolidation. The point is that the migration shape of 2026, across Astro 7's Vite 8 Rust compiler, Oxc's incremental tree-shake progress, and now Cline's SDK move, is a sequence of large architecture rewrites shipped in stages rather than as one big bang. Cline 4.0.1 is what an honest "stage 1 of the migration" looks like when the stable path has to keep working.
