---
title: "Cline 4.0.1 annule la migration SDK après les régressions de 4.0.0 ; 4.0.2 ramène le code SDK avec des correctifs pour l'effort de raisonnement et ClinePass"
description: "Cline a publié v4.0.1 le 28 juin 2026 et v4.0.2 le 29 juin 2026 (github.com/cline/cline), un cycle de récupération en deux étapes pour la migration SDK de v4.0.0 livrée le 26 juin. v4.0.1 livre l'extension VS Code 3.89.x d'avant le SDK sous un numéro de version 4.0.1, construite à partir d'une branche dédiée `legacy-extension` via un nouveau workflow `ext-vscode-publish-legacy.yml`, pour résoudre les régressions signalées dans 4.0.0 (aperçus de diff cassés dans l'éditeur, erreurs run_commands pendant les éditions de fichiers, flux d'édition de fichiers cassé avec GLM 5.2 et MiniMax M3 via Ollama). v4.0.2 restaure le chemin de code basé sur le SDK par-dessus la même branche legacy, en ajoutant le support de l'effort de raisonnement (incluant `xhigh`) pour les modèles thinking de DeepSeek (#11938), une couche de contrôle d'effort de raisonnement centralisée pour ClinePass (#11954), des identifiants Z.ai canoniques (#11951), un correctif de remplacement des variables d'environnement dans la webview (#11955), un polissage des métadonnées ClinePass et Z.ai (#11958), et un correctif de paramètre par défaut pour focus chain (#11960). La CLI v3.0.32 sort le même jour avec les améliorations de compaction de contexte du SDK v0.0.54 et le polissage de l'onboarding ClinePass. La séquence montre un projet qui récupère une migration majeure en 72 heures en faisant avancer la branche legacy plutôt qu'en annulant le travail SDK."
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) le 28 juin 2026 a fait reculer l'extension VS Code stable vers la base de code 3.89.x d'avant le SDK, livrée sous un numéro de version 4.0.1 pour que les utilisateurs existants de 4.0.0 reçoivent la mise à jour. Les notes de version sont explicites : « Roll the stable VS Code extension back to the pre-SDK-migration codebase to resolve regressions reported in 4.0.0. » Le build provient d'une branche dédiée `legacy-extension` via un nouveau workflow `ext-vscode-publish-legacy.yml` ; le `ext-vscode-publish-stable.yml` principal (basé sur Bun) reste le chemin pour publier `main` une fois que la migration SDK sera stabilisée."
  - "Les régressions de 4.0.0 qui ont motivé l'annulation sont documentées dans des issues publiques : l'aperçu de diff dans l'éditeur VS Code a cessé d'afficher les modifications de fichiers ([#11934](https://github.com/cline/cline/issues/11934)), les éditions de fichiers se cassaient avec des erreurs `run_commands` pour les modèles locaux ([#11907](https://github.com/cline/cline/issues/11907)), et GLM 5.2 plus MiniMax M3 via Ollama ont été décrits dans les commentaires comme « basically unusable ». Les deux rapporteurs notent que revenir à 3.89.2 rétablissait le comportement normal. La base de code 3.x était déjà une extension basée sur npm sur une piste séparée, donc l'annulation n'annule pas le travail de migration SDK sur `main` ; elle détache simplement le chemin de publication stable."
  - "[v4.0.2](https://github.com/cline/cline/releases/tag/v4.0.2) le 29 juin ramène le chemin de code du SDK avec huit commits de correctifs et de fonctionnalités : support de l'effort de raisonnement incluant `xhigh` pour les modèles thinking de DeepSeek ([#11938](https://github.com/cline/cline/pull/11938)), identifiants Z.ai canoniques ([#11951](https://github.com/cline/cline/pull/11951)), support d'effort de raisonnement centralisé pour ClinePass ([#11954](https://github.com/cline/cline/pull/11954)), correctif de remplacement des variables d'environnement dans la webview ([#11955](https://github.com/cline/cline/pull/11955)), polissage des métadonnées ClinePass et Z.ai ([#11958](https://github.com/cline/cline/pull/11958)), et un correctif de paramètre par défaut pour focus chain dans la webview ([#11960](https://github.com/cline/cline/pull/11960)). [CLI v3.0.32](https://github.com/cline/cline/releases/tag/cli-v3.0.32) sort le même jour sur SDK v0.0.54 avec une meilleure précision de compaction de contexte et des messages d'erreur plus clairs."
faq:
  - question: "Que s'est-il passé avec Cline 4.0 ?"
    answer: "Cline 4.0.0 (26 juin 2026) avait migré l'extension VS Code sur le SDK Cline partagé, mais la migration a été livrée avec des régressions : l'aperçu de diff dans l'éditeur a cessé d'afficher les modifications de fichiers (issue #11934), les éditions de fichiers se cassaient avec des erreurs run_commands pour les modèles locaux (issue #11907), et certains fournisseurs comme GLM 5.2 et MiniMax M3 via Ollama ont été décrits comme « basically unusable ». Cline 4.0.1 (28 juin) a fait reculer l'extension VS Code vers la base de code 3.89.x d'avant le SDK, livrée depuis une branche dédiée `legacy-extension` sous un numéro de version 4.0.1, via un nouveau workflow de publication legacy. Cline 4.0.2 (29 juin) a restauré le chemin de code basé sur le SDK avec le support de l'effort de raisonnement pour les modèles thinking de DeepSeek, une couche d'effort de raisonnement ClinePass centralisée, des identifiants Z.ai canoniques, un correctif de remplacement des variables d'environnement dans la webview, un polissage des métadonnées ClinePass et un correctif de paramètre par défaut pour focus chain."
  - question: "Quelles régressions Cline 4.0.0 a-t-il livrées ?"
    answer: "Deux issues ont documenté les régressions qui ont motivé l'annulation. L'issue #11934 signalait que l'aperçu de diff de VS Code avait cessé d'afficher les modifications de fichiers après la mise à jour vers 4.0.0 ; seuls les boutons Approve et Reject apparaissaient sans aucun diff. L'issue #11907 signalait que `run_commands` échouait pendant les éditions de fichiers sur des modèles locaux ; le rapporteur et un commentateur de suivi (utilisant GLM 5.2 et MiniMax M3 via Ollama) ont signalé le même flux d'édition cassé et noté que revenir à 3.89.2 rétablissait le comportement normal. Le commentateur de suivi a conclu que la 4.0 rendait Cline « basically unusable » pour ce flux de travail. Les régressions étaient suffisamment graves pour que le projet livre une annulation dans les 48 heures suivant la publication de 4.0.0."
  - question: "Pourquoi Cline 4.0.1 a-t-il été publié depuis une branche legacy-extension ?"
    answer: "Cline 4.0.1 est publié depuis une branche dédiée `legacy-extension` via un nouveau workflow `ext-vscode-publish-legacy.yml`. Le commentaire du workflow explique le choix de conception : la branche contient la base de code 3.89.x basée sur npm, avancée sous une version 4.0.x pour que les utilisateurs existants de 4.0.0 reçoivent toujours la mise à jour, tandis que le workflow principal `ext-vscode-publish-stable.yml` (basé sur Bun) reste le chemin pour publier `main` une fois que la migration SDK sera stabilisée. La porte CI exécute la propre suite de tests npm de la branche legacy plutôt que la suite basée sur Bun sur `main`, parce que le code legacy ne peut pas passer le chemin de test Bun. C'est le même schéma de récupération qu'une branche de correctif : ne pas annuler le travail SDK, simplement détacher le chemin de publication."
  - question: "Que change Cline 4.0.2 ?"
    answer: "Cline 4.0.2 restaure le chemin de code basé sur le SDK par-dessus la branche legacy et livre huit commits de correctifs et de fonctionnalités. La fonctionnalité phare est le support de l'effort de raisonnement incluant `xhigh` pour les modèles thinking de DeepSeek (#11938), avec un correctif qui ne transmet pas `none` à l'API du fournisseur et qui limite le sélecteur d'effort de raisonnement aux modèles capables de thinking. L'expérience du fournisseur ClinePass est améliorée (#11950), les contrôles d'effort de raisonnement ClinePass sont centralisés pour que le même composant gère l'effort de raisonnement entre fournisseurs (#11954), les identifiants Z.ai sont canonisés vers l'ensemble recommandé (#11951), le remplacement des variables d'environnement dans la webview est corrigé (#11955), les métadonnées ClinePass et Z.ai sont polies (#11958), et les paramètres par défaut de focus chain sont corrigés dans l'état de la webview (#11960)."
  - question: "Qu'est-ce qui a changé dans Cline CLI v3.0.32 ?"
    answer: "Cline CLI v3.0.32 est sorti le 29 juin 2026 sur SDK v0.0.54, le même jour que v4.0.2. La version CLI ajoute une étape intermédiaire avant la sélection de modèle ClinePass, rend l'écran d'abonnement ClinePass sélectionnable, promeut ClinePass dans l'avis de démarrage, utilise « ClinePass » en un seul mot de manière cohérente dans l'interface CLI, affine le texte du fournisseur ClinePass, et tire une meilleure précision de compaction de contexte et des messages d'erreur plus clairs depuis SDK v0.0.54. La ligne CLI a continué à être publiée en parallèle de l'annulation de l'extension plutôt que de bloquer dessus."
  - question: "La migration du SDK Cline est-elle annulée ?"
    answer: "Non. Le travail de migration SDK continue séparément sur `main` ; v4.0.1 n'a fait reculer que le chemin de publication stable pour l'extension VS Code, pas le code SDK sous-jacent. La ligne CLI v3.0.32, le tableau de tâches Cline Kanban et le plugin JetBrains ont continué à être publiés sur le SDK partagé pendant toute l'annulation. v4.0.2 a ramené le chemin de code de l'extension basé sur le SDK avec huit commits de correctifs, ce qui veut dire que la migration est en cours de stabilisation en production plutôt qu'abandonnée. La leçon est structurelle : quand une migration casse le chemin stable, publiez la branche legacy vers l'avant et continuez à travailler sur `main`."
---

[Cline v4.0.1](https://github.com/cline/cline/releases/tag/v4.0.1), publié le 28 juin 2026, est l'une des publications stables les plus inhabituelles de l'histoire récente de l'outillage IA. Ses [notes de version](https://github.com/cline/cline/releases/tag/v4.0.1) tiennent en une ligne : « 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`. » Quarante-huit heures plus tôt, [Cline v4.0.0](https://github.com/cline/cline/releases/tag/v4.0.0) avait migré l'extension VS Code sur le [SDK Cline](https://docs.cline.bot/cline-sdk/overview) partagé, le changement d'architecture phare couvert dans [l'article Cline 4.0 du 27 juin](/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), publié le 29 juin (le jour où cet article sort), ramène le chemin de code basé sur le SDK avec le support de l'effort de raisonnement pour les modèles thinking de DeepSeek, une couche de raisonnement ClinePass centralisée, et une série de correctifs pour les fournisseurs et la webview. La séquence de 72 heures est un exemple travaillé de la façon dont une migration majeure peut être récupérée sans annuler le travail lui-même.

## Ce que l'annulation a réellement livré

La migration SDK de 4.0.0 était en chantier depuis des mois ; la [vue de comparaison entre v3.89.2 et v4.0.0](https://github.com/cline/cline/compare/v3.89.2...v4.0.0) montre que l'extension entière est passée de son implémentation de tâches historique basée sur npm à un runtime TypeScript partagé qui alimente aussi la CLI Cline, [Kanban](https://github.com/cline/kanban) et le plugin JetBrains. Dans les heures qui ont suivi la publication stable, deux issues GitHub ont décrit des régressions que les utilisateurs existants de la 3.x ne voyaient pas. L'issue [#11934](https://github.com/cline/cline/issues/11934), ouverte le matin après la sortie de 4.0.0, signalait que « 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. » L'issue [#11907](https://github.com/cline/cline/issues/11907), ouverte tard le 27 juin, signalait des erreurs `run_commands` pendant les éditions de fichiers sur des modèles Qwen locaux. Les deux rapporteurs notaient que revenir à 3.89.2 rétablissait immédiatement le comportement normal.

Les commentaires de suivi sur #11907 sont ce qui a façonné la décision d'annuler. Un commentateur utilisant GLM 5.2 et MiniMax M3 via Ollama a écrit qu'après la mise à jour 4.0 Cline était devenu « basically unusable » parce que « 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. » Le commentaire pointait vers le commit #11801 comme coupable probable, et proposait un correctif manuel de la distribution bundled `@cline/core`. C'est le type de signalement qu'un projet ne veut pas traiter un utilisateur à la fois. Le correctif était structurel : faire avancer l'extension legacy et laisser le travail SDK sur `main`.

## La branche `legacy-extension` et un workflow de publication dédié

Le mécanisme est la partie intéressante. Cline n'a annulé aucun commit sur `main` ; le travail de migration SDK a continué sur place. À la place, le projet a créé une branche séparée `legacy-extension` qui contient la base de code 3.89.x basée sur npm, et un nouveau workflow [`ext-vscode-publish-legacy.yml`](https://github.com/cline/cline/blob/main/.github/workflows/ext-vscode-publish-legacy.yml) qui publie depuis cette branche. Le commentaire du workflow explique le choix de conception :

> 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.

Le workflow inline aussi sa propre suite de tests npm de l'extension legacy plutôt que de réutiliser le `.github/workflows/ext-vscode-test.yml` partagé, parce que cette suite sur `main` est basée sur Bun et testerait la mauvaise branche. Le workflow legacy checkout la branche `legacy-extension`, exécute `npm --prefix apps/vscode ci`, puis exécute `npm run ci:check-all`, `npm run ci:build`, les tests unitaires, les tests d'intégration de l'extension et les tests de la webview. Le tag de release est dérivé de la version du package sur la branche legacy, le changelog doit commencer par le nouveau titre de version, et le tag n'est créé que s'il n'existe pas déjà sur `origin`. C'est la forme en production d'une récupération de type « il faut faire avancer l'ancien code pendant qu'on corrige le nouveau ».

La [vue de comparaison entre v4.0.0 et v4.0.1](https://github.com/cline/cline/compare/v4.0.0...v4.0.1) est en conséquence courte : un seul commit `chore(vscode): bump to 4.0.1 for legacy rollback release`, plus les bumps de `CHANGELOG.md` et `apps/vscode/package.json`. Tout le reste est sur la branche `legacy-extension`. Le même schéma explique pourquoi un tag `4.0.1` peut livrer la base de code 3.89.2 : la version est avancée, la branche legacy est la source de vérité, et la migration SDK reste intacte sur `main` pour le retour stable éventuel.

## Ce que v4.0.2 a ramené

[v4.0.2](https://github.com/cline/cline/releases/tag/v4.0.2), publié le matin du 29 juin, ramène le chemin de code basé sur le SDK sur la branche legacy avec huit commits de correctifs et de fonctionnalités. La [vue de comparaison entre v4.0.1 et v4.0.2](https://github.com/cline/cline/compare/v4.0.1...v4.0.2) est le vrai signal que la migration SDK est en cours de stabilisation plutôt qu'abandonnée.

La fonctionnalité phare est le support de l'effort de raisonnement incluant `xhigh` pour les modèles thinking de DeepSeek ([#11938](https://github.com/cline/cline/pull/11938)). La PR ajoute un sélecteur d'effort de raisonnement limité aux modèles capables de thinking et un correctif qui ne transmet pas `none` à l'API du fournisseur, pour que le modèle lui-même, pas le wrapper du fournisseur, décide quand sauter la sortie de raisonnement. Une PR de suivi ([#11954](https://github.com/cline/cline/pull/11954)) centralise la couche de support de l'effort de raisonnement pour que le même composant gère le paramètre entre ClinePass et les fournisseurs directs, avec un correctif qui expose les contrôles d'effort de raisonnement pour les modèles ClinePass et normalise le flag include du raisonnement budget de Claude.

Trois autres commits serrent la surface des fournisseurs ClinePass et Z.ai. [#11950](https://github.com/cline/cline/pull/11950) améliore l'UX du fournisseur ClinePass avec une étape intermédiaire avant la sélection de modèle et un chemin de repli pour les actions ClinePass. [#11951](https://github.com/cline/cline/pull/11951) préfère les identifiants Z.ai canoniques et supprime le filtrage d'alias redondant côté Cline. [#11958](https://github.com/cline/cline/pull/11958) polit les métadonnées ClinePass et Z.ai. [#11955](https://github.com/cline/cline/pull/11955) corrige le remplacement des variables d'environnement dans la webview, qui s'était silencieusement cassé pour l'interpolation de templates dans l'extension basée sur le SDK. [#11960](https://github.com/cline/cline/pull/11960) définit les paramètres par défaut de focus chain dans l'état de la webview pour que le toggle reflète la bonne valeur au chargement.

Le commit de release, `chore(vscode): bump to 4.0.2 for legacy release`, est du même type que le bump de version de 4.0.1, mais le diff dans la vue de comparaison rend clair que 4.0.2 n'est plus une annulation pure ; c'est le chemin de code du SDK qui revient sur la branche legacy avec une série de correctifs que le projet a collectés pendant que l'extension stable tournait sur 3.89.x.

## CLI v3.0.32 arrive sur SDK v0.0.54 le même jour

La ligne CLI a continué à être publiée sur le SDK partagé pendant toute l'annulation de l'extension, et [CLI v3.0.32](https://github.com/cline/cline/releases/tag/cli-v3.0.32) est sorti le même matin que v4.0.2 sur SDK v0.0.54. Les notes de version CLI listent cinq changements : une étape intermédiaire avant la sélection de modèle ClinePass, un écran d'abonnement ClinePass sélectionnable, la promotion de ClinePass dans l'avis de démarrage, l'utilisation cohérente de « ClinePass » en un seul mot dans l'interface CLI, et une meilleure précision de compaction de contexte et des messages d'erreur plus clairs tirés de SDK v0.0.54. Le correctif de compaction côté SDK ([#11894](https://github.com/cline/cline/pull/11894), la veille) était une amélioration basique du budget de tokens qui a été livrée à la CLI sans attendre que l'annulation de l'extension se stabilise.

Le découpage est instructif. La CLI, Kanban et le plugin JetBrains n'ont jamais été annulés, parce que les régressions de migration SDK sur la surface CLI étaient différentes et moins graves que les régressions d'édition de fichiers et d'aperçu de diff sur l'extension VS Code. Le chemin de publication legacy est spécifique à l'extension, ce qui suggère que la récupération a été motivée par les régressions de diff et d'édition VS Code, pas par une défaillance SDK plus générale.

## À surveiller

Trois signaux à monitorer sur la semaine à venir. Premièrement, quand la prochaine release de l'extension VS Code sortira du workflow principal `ext-vscode-publish-stable.yml` plutôt que du workflow legacy, la migration SDK sera considérée comme stabilisée. Le workflow legacy note explicitement qu'il sert à « releasing `main` once the SDK migration is solid », donc le chemin de retour est observable dans l'onglet Actions. Deuxièmement, surveillez la fermeture des threads [#11934](https://github.com/cline/cline/issues/11934) et [#11907](https://github.com/cline/cline/issues/11907) par un correctif 4.0.x plutôt qu'un patch manuel ; si le lot de huit commits de 4.0.2 les ferme, les régressions d'édition de fichiers sont résolues. Troisièmement, la ligne SDK ([`@cline/sdk`](https://docs.cline.bot/cline-sdk/overview)) est désormais publique pour les développeurs qui construisent leurs propres agents, et la release v0.0.54 a été la première release SDK livrée en parallèle d'une extension connue cassée ; si v0.0.55 ou v0.0.56 inclut une note « tested against the stable extension », les lignes extension et SDK ont reconvergé.

La leçon plus large est structurelle. Quand une migration majeure casse le chemin stable, l'option la moins coûteuse est d'annuler la migration et de recommencer ; Cline a plutôt détaché le chemin de publication (branche legacy, workflow dédié, suite de tests inline) et laissé le travail SDK continuer sur `main` pendant que les utilisateurs 3.89.x recevaient les mises à jour. Le même schéma est apparu chez [OpenAI avec le travail de gouvernance Codex 0.142](/articles/2026-06-27--openai-codex-0-142-token-budgets-multi-agent-web-search) quand le relais Noise 0.141 a été livré en premier pour durcir le transport, et chez [Vinext avec le travail d'adaptateurs Cloudflare/Vercel](/articles/vinext-cloudflare-vercel) quand le framework a livré les adaptateurs avant la consolidation du runtime. Le point est que la forme des migrations de 2026, à travers [Astro 7 et son compilateur Rust Vite 8](/articles/2026-06-22--astro-7-stable-vite8-rust-compiler-ai-agents), [les progrès incrémentaux de tree-shake d'Oxc](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf), et maintenant le passage au SDK de Cline, est une séquence de grosses réécritures d'architecture livrées par étapes plutôt qu'en un seul big bang. Cline 4.0.1 est à quoi ressemble une honnête « étape 1 de la migration » quand le chemin stable doit continuer à fonctionner.