Balíček Cline 4.1 obsahuje dvě celá rozšíření. Které se spustí, řídí vzdálený příznak
Vydání 4.1 rozšíření Cline pro Visual Studio Code sloučilo starou a novou verzi do jednoho balíčku: uvnitř leží obě vedle sebe a při každém otevření okna vybere zavaděč jednu z nich. Rozhoduje o tom příznak na serveru, ne nastavení editoru. Balíček jsme stáhli a rozbalili – obě větve v něm opravdu jsou a s nimi manifest, který každé skupině uživatelů schová část tlačítek té druhé.
Cline je rozšíření editoru Visual Studio Code, které v něm dělá agenta: přečte zadání, prochází soubory, mění je a spouští příkazy v terminálu. V obchodě Visual Studio Marketplace má přes 4,8 milionu instalací. Vydání 4.1.0 z 31. července na něm navenek nezměnilo skoro nic. Změnilo se, co se uživateli nainstaluje.
V balíčku nově leží dvě úplná rozšíření vedle sebe: staré, kterému Cline říká „legacy“, a nové, postavené na vlastním SDK, označované „next“. Vstupním bodem není ani jedno z nich, ale malý zavaděč, který při otevření každého okna editoru spustí právě jedno. Které, o tom rozhoduje příznak na serveru.
Co v tom balíčku je
Balíček jsme si stáhli z obchodu a rozbalili. Verze 4.1.2 má 19 343 759 bajtů, tedy 18,4 MB, a po rozbalení 85,5 MB v 97 položkách. Adresář legacy z toho zabírá 52,9 MB ve 44 souborech, adresář next 32,5 MB ve 29 souborech. Poslední vydání před sloučením, 4.0.12 z 28. července, mělo 10 430 223 bajtů – ke stažení je tedy nová verze skoro dvakrát větší než ta předchozí.
Vstupní soubor extension.js, na který ukazuje pole main v manifestu, měří 25 127 bajtů. To je ten zavaděč. Dokumentace v repozitáři mu přisuzuje zhruba 40 kB; ve vydaném balíčku je o dobrou třetinu menší.
Kdo vybírá, které rozšíření poběží
Rozhodnutí padá dvakrát a pokaždé jinde. Při startu okna přečte zavaděč uloženou volbu z vlastního úložiště v editoru – synchronně a bez dotazu na síť –, nastaví kontextový klíč cline.sdkBundle a načte jedno ze dvou rozšíření. Teprve potom se na pozadí zeptá serveru a odpověď uloží pro příští okno. Změna na serveru tedy nikdy nepřepne okno, které už běží.
Tím serverem je PostHog, služba na příznaky funkcí, a příznak se jmenuje ext-sdk-bundle-rollout. Je to obyčejný logický příznak s procentem: zavaděč přepne na nové rozšíření jen tehdy, když dostane doslovné true. Cokoli jiného – jiná hodnota, výpadek, chybějící klíč – znamená staré rozšíření. Vyhodnocuje se proti identifikátoru stroje, tomu samému, pod kterým rozšíření posílá telemetrii.
Pojistky jsou dvě. Když nové rozšíření při startu spadne, zavaděč uklidí, co stihlo zaregistrovat, spustí staré a tuhle verzi si na daném stroji ke starému rozšíření přišpendlí; další vydání dostane novou šanci. Uživatel má vlastní páku: nastavení cline.rollout.bundleOverride s hodnotami auto, next a legacy přebije vzdálené přiřazení oběma směry a projeví se po znovunačtení okna. V manifestu staženého balíčku to nastavení opravdu je, včetně těch tří hodnot.
Dvě skupiny, jiná tlačítka
Manifest rozšíření čte editor dřív, než se spustí jakýkoli kód, takže musí posloužit oběma skupinám naráz. Cline ho proto skládá ze dvou manifestů a položky, které má jen jedna strana, podmiňuje kontextovým klíčem. Ve verzi 4.1.2 je takových položek devět. Nejvíc je vidět tlačítko v hlavičce postranního panelu: nová větev tam volá příkaz cline.marketplaceButtonClicked, stará cline.mcpButtonClicked.
Rozdíly nekončí u tlačítek. Poznámky k vydání uvádějí, že úlohy založené v nové větvi se ve staré nezobrazí – nemažou se, vrátí se, až stroj přejde zpátky. Dokumentace k tomu přidává, že přihlašovací údaje obměněné v nové větvi si ve staré můžou vyžádat nové přihlášení. Nastavení a datové úložiště jsou naopak společné.
Proč tahle oklika
Obchod s rozšířeními pro Visual Studio Code neumí rozeslat novou verzi po částech: jakmile je publikovaná, dostane ji každý, kdo nemá vypnuté automatické aktualizace. Požádal o to už v lednu 2023 vydavatel rozšíření pro jazyk Go. Hlášení v repozitáři VS Code zavřeli týž den jako dotaz, přesunuté hlášení č. 550 u obchodu je k 1. srpnu 2026 pořád otevřené. Má štítky Type:Feature a Priority:2, dva komentáře a poslední pohyb 31. července 2025. Odpověď provozovatele v něm není žádná.
U rozšíření s 4,8 milionu instalací je to rozdíl mezi „chyba potká procento uživatelů“ a „chyba potká všechny“. Jak se aktualizace dostane k uživateli, řeší každý agentní nástroj po svém; jinde je odpovědí samostatný stabilní kanál, který jde záměrně pozadu.
Co se zvenčí ověřit nedá
Kolik procent uživatelů má zrovna běžet na nové větvi, se zjistit nedá – příznak sedí v účtu Cline. Poznámky k vydání mluví o startu na 1 %, návod v repozitáři popisuje postup 0 %, 1 %, 5 %, 25 % a 100 %. Ověřit jde jen to, co je v balíčku.
Druhá věc stojí v dokumentaci natvrdo: vyhodnocení příznaku běží vždycky. Vypnutá telemetrie zastaví odeslání události o rozhodnutí zavaděče, ne samotný dotaz, kterým si zavaděč o přiřazení říká. Kdo telemetrii vypnul, o zařazení do skupiny tím nepřijde.
Třetí: sloučený balíček je dočasný. Návod počítá s tím, že až nová větev doběhne na 100 % a chvíli vydrží, vyjde obyčejné rozšíření bez zavaděče a celý tenhle mezikus se z repozitáře smaže.
Tři verze za hodinu a půl
V obchodě se 4.1.0 objevila v 3:55 UTC, 4.1.1 v 4:37 a 4.1.2 v 5:29 – tři verze za 94 minut. První oprava vyhodila z evidence serverů MCP vnitřní náhodný klíč držený jen v paměti; volání nástrojů se nově směrují podle jména serveru, takže směrování přežije restart i změnu seznamu serverů. Druhá přidala do nastavení na stránku s informacemi o rozšíření údaj, která z obou větví je vedle čísla verze zrovna aktivní.
Náš názor: ta druhá oprava přišla hodinu a půl po rozdělení uživatelů do dvou skupin, a přitom bez ní by nikdo, kdo hlásí chybu, neuměl říct, které z obou rozšíření mu ji vyrobilo.