--- title: "Cline 4.0.1 Rolls Back the SDK Migration After 4.0.0 Regressions; 4.0.2 Brings the SDK Code Back with Reasoning Effort and ClinePass Fixes" description: "Cline shipped v4.0.1 on June 28, 2026 and v4.0.2 on June 29, 2026 (github.com/cline/cline), a two-step recovery cycle for the v4.0.0 SDK migration that landed on June 26. v4.0.1 ships the pre-SDK 3.89.x VS Code extension under a 4.0.1 version number, built from a dedicated `legacy-extension` branch via a new `ext-vscode-publish-legacy.yml` workflow, to resolve regressions reported in 4.0.0 (broken diff previews in the editor, run_commands errors during file edits, broken file-editing flow with GLM 5.2 and MiniMax M3 through Ollama). v4.0.2 restores the SDK-backed code path on top of the same legacy branch, adding reasoning effort support (including `xhigh`) for DeepSeek thinking models (#11938), a centralized reasoning effort control layer for ClinePass (#11954), canonical Z.ai model ids (#11951), webview env replacement fix (#11955), ClinePass and Z.ai metadata polish (#11958), and a default focus chain settings fix (#11960). CLI v3.0.32 ships the same day with SDK v0.0.54 context-compaction improvements and ClinePass onboarding polish. The release sequence shows a project recovering a major migration in 72 hours by tagging the legacy branch forward rather than reverting the SDK work." date: 2026-06-29 image: "/images/heroes/2026-06-29--cline-4-0-1-rollback-sdk-migration-v4-0-2-restores.png" author: lschvn tags: ["ai", "tooling"] tldr: - "Cline [v4.0.1](https://github.com/cline/cline/releases/tag/v4.0.1) on June 28, 2026 rolled the stable VS Code extension back to the pre-SDK 3.89.x codebase, shipped under a 4.0.1 version number so existing 4.0.0 users receive the update. The release notes are explicit: 'Roll the stable VS Code extension back to the pre-SDK-migration codebase to resolve regressions reported in 4.0.0.' The build comes from a dedicated `legacy-extension` branch via a new `ext-vscode-publish-legacy.yml` workflow; the main `ext-vscode-publish-stable.yml` (bun-based) stays the path for releasing `main` once the SDK migration is solid." - "The 4.0.0 regressions that drove the rollback are documented in public issues: the diff preview in the VS Code editor stopped rendering file changes ([#11934](https://github.com/cline/cline/issues/11934)), file edits broke with `run_commands` errors for local models ([#11907](https://github.com/cline/cline/issues/11907)), and GLM 5.2 plus MiniMax M3 through Ollama were described in comments as 'basically unusable.' Both reporters note that reverting to 3.89.2 restored normal behavior. The 3.x codebase was already an npm-based extension on a separate track, so the rollback does not undo the SDK migration work on `main`; it just detaches the stable ship path." - "[v4.0.2](https://github.com/cline/cline/releases/tag/v4.0.2) on June 29 ships the SDK code path back with eight fix and feature commits: reasoning effort support including `xhigh` for DeepSeek thinking models ([#11938](https://github.com/cline/cline/pull/11938)), canonical Z.ai model ids ([#11951](https://github.com/cline/cline/pull/11951)), centralized reasoning effort support for ClinePass ([#11954](https://github.com/cline/cline/pull/11954)), webview env replacement fix ([#11955](https://github.com/cline/cline/pull/11955)), ClinePass and Z.ai metadata polish ([#11958](https://github.com/cline/cline/pull/11958)), and a focus chain default settings fix ([#11960](https://github.com/cline/cline/pull/11960)). [CLI v3.0.32](https://github.com/cline/cline/releases/tag/cli-v3.0.32) ships the same day on SDK v0.0.54 with context-compaction accuracy and error-message improvements." faq: - question: "What happened to Cline 4.0?" answer: "Cline 4.0.0 (June 26, 2026) migrated the VS Code extension onto the shared Cline SDK, but the migration shipped with regressions: the diff preview in the editor stopped rendering file changes (issue #11934), file edits broke with run_commands errors for local models (issue #11907), and some providers like GLM 5.2 and MiniMax M3 through Ollama were described as 'basically unusable.' Cline 4.0.1 (June 28) rolled the VS Code extension back to the pre-SDK 3.89.x codebase, shipped from a dedicated `legacy-extension` branch under a 4.0.1 version number, via a new legacy publish workflow. Cline 4.0.2 (June 29) restored the SDK-backed code path with reasoning effort support for DeepSeek thinking models, a centralized ClinePass reasoning effort layer, canonical Z.ai model ids, webview env replacement fix, ClinePass metadata polish, and a focus chain settings default fix." - question: "What regressions did Cline 4.0.0 ship with?" answer: "Two issues documented the regressions that drove the rollback. Issue #11934 reported that the VS Code diff preview stopped showing file changes after updating to 4.0.0; only Approve and Reject buttons appeared with no diff. Issue #11907 reported that `run_commands` failed during file edits on local models; the reporter and a follow-up commenter (using GLM 5.2 and MiniMax M3 through Ollama) both reported the same broken editing flow and noted that reverting to 3.89.2 restored normal behavior. The follow-up commenter concluded that 4.0 made Cline 'basically unusable' for that workflow. The regressions were severe enough that the project shipped a rollback within 48 hours of the 4.0.0 release." - question: "Why did Cline 4.0.1 ship from a legacy-extension branch?" answer: "Cline 4.0.1 ships from a dedicated `legacy-extension` branch via a new `ext-vscode-publish-legacy.yml` workflow. The workflow comment explains the design: the 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, while the main `ext-vscode-publish-stable.yml` workflow (bun-based) stays the path for releasing `main` once the SDK migration is solid. The CI gate runs the legacy branch's own npm-based test suite rather than the bun-based suite on `main`, because the legacy code cannot pass the bun test path. This is the same recovery pattern as a hotfix branch: do not revert the SDK work, just detach the ship path." - question: "What does Cline 4.0.2 change?" answer: "Cline 4.0.2 restores the SDK-backed code path on top of the legacy branch and ships eight commits of fixes and features. The headline feature is reasoning effort support including `xhigh` for DeepSeek thinking models (#11938), with a fix that does not forward 'none' reasoning effort to the API and scopes the reasoning effort selector to thinking-capable models. The ClinePass provider experience is improved (#11950), ClinePass reasoning controls are centralized so the same component handles reasoning effort across providers (#11954), Cline Z.ai model ids are canonicalized to the recommended set (#11951), webview environment variable replacement is fixed (#11955), ClinePass and Z.ai model metadata is polished (#11958), and the focus chain default settings are corrected in webview state (#11960)." - question: "What changed in Cline CLI v3.0.32?" answer: "Cline CLI v3.0.32 shipped on June 29, 2026 on SDK v0.0.54, the same day as v4.0.2. The CLI release adds an intermediate step before ClinePass model selection, makes the ClinePass subscription screen selectable, promotes ClinePass in the startup notice, uses 'ClinePass' as one word consistently in the UI, refines the ClinePass provider copy, and pulls in more accurate context compaction and clearer error messages from SDK v0.0.54. The CLI line continued to ship alongside the extension rollback rather than blocking on it." - question: "Is the Cline SDK migration cancelled?" answer: "No. The SDK migration work continues separately on `main`; v4.0.1 only rolled back the stable ship path for the VS Code extension, not the underlying SDK code. The CLI v3.0.32 line, the Cline Kanban task board, and the JetBrains plugin continued to ship on the shared SDK throughout the rollback. v4.0.2 shipped the SDK-backed extension code path back with eight commits of fixes, which means the migration is being stabilized in production rather than abandoned. The lesson is structural: when a migration breaks the stable path, ship the legacy branch forward and keep working on `main`." --- [Cline v4.0.1](https://github.com/cline/cline/releases/tag/v4.0.1), released June 28, 2026, is one of the more unusual stable releases in recent AI tooling history. Its [release notes](https://github.com/cline/cline/releases/tag/v4.0.1) 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](https://github.com/cline/cline/releases/tag/v4.0.0) had migrated the VS Code extension onto the shared [Cline SDK](https://docs.cline.bot/cline-sdk/overview), the headline architectural change covered in the [June 27 Cline 4.0 piece](/articles/2026-06-27--cline-4-0-sdk-rewrite-clinepass-customize-marketplace-plugins). [v4.0.2](https://github.com/cline/cline/releases/tag/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](https://github.com/cline/cline/compare/v3.89.2...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](https://github.com/cline/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](https://github.com/cline/cline/issues/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](https://github.com/cline/cline/issues/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`](https://github.com/cline/cline/blob/main/.github/workflows/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-extension` branch. 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 main `ext-vscode-publish-stable.yml` workflow (bun-based) stays the path for releasing `main` once 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](https://github.com/cline/cline/compare/v4.0.0...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](https://github.com/cline/cline/releases/tag/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](https://github.com/cline/cline/compare/v4.0.1...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](https://github.com/cline/cline/pull/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](https://github.com/cline/cline/pull/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](https://github.com/cline/cline/pull/11950) improves the ClinePass provider UX with an intermediate step before model selection and a fallback path for ClinePass actions. [#11951](https://github.com/cline/cline/pull/11951) prefers canonical Z.ai model ids and removes redundant alias filtering on the Cline side. [#11958](https://github.com/cline/cline/pull/11958) polishes ClinePass and Z.ai model metadata. [#11955](https://github.com/cline/cline/pull/11955) fixes webview environment variable replacement, which had silently broken template interpolation in the SDK-backed extension. [#11960](https://github.com/cline/cline/pull/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](https://github.com/cline/cline/releases/tag/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](https://github.com/cline/cline/pull/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](https://github.com/cline/cline/issues/11934) and [#11907](https://github.com/cline/cline/issues/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`](https://docs.cline.bot/cline-sdk/overview)) 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](/articles/2026-06-27--openai-codex-0-142-token-budgets-multi-agent-web-search) when the 0.141 Noise relay shipped first to harden the transport, and at [Vinext's Cloudflare/Vercel adapter work](/articles/vinext-cloudflare-vercel) 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](/articles/2026-06-22--astro-7-stable-vite8-rust-compiler-ai-agents), [Oxc's incremental tree-shake progress](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf), 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.