OpenClaw 4.20 e 4.21: Kimi K2.6 di default, GPT Image 2 e un'altra falla di auth rattoppata

OpenClaw 4.20 porta Kimi K2.6 come modello di default e un bel po’ di lavoro infrastrutturale, ma rompe Telegram e fa sparire API key. La 4.21, arrivata sette ore dopo, è un hotfix chirurgico che aggiunge GPT Image 2 e chiude la seconda vulnerabilità di auth in due mesi.

Fonte: Reddit r/myclaw, GitHub, OpenClaw release notes

Perché ti dovrebbe interessare

Se usi OpenClaw in produzione, queste due release ti toccano direttamente. La 4.20 cambia il modello di default e ristruttura diversi sottosistemi interni, con conseguenze reali sulla stabilità. La 4.21 corregge un problema di sicurezza che poteva permettere a chiunque su un canale con configurazione permessiva di eseguire comandi owner-only. E poi c’è il solito tema: aggiornare subito o aspettare che si posi la polvere.

4.20: Kimi K2.6 prende il volante

La feature principale è il default a Kimi K2.6. Il modello di Moonshot è andato in GA il 21 aprile e OpenClaw si è mosso in fretta: tutte le superfici Moonshot bundled, dalla web search al media understanding, ora puntano a kimi-k2.6 mantenendo kimi-k2.5 per compatibilità.

È più importante di quanto sembri. Kimi K2.6 non è un bump incrementale su K2.5. È un modello agentic di produzione: 1 trilione di parametri (MoE, 384 expert, 32B attivi per token), finestra di contesto da 262K token con compressione automatica, e capacità di coordinare fino a 300 sub-agent in 4.000 step in un singolo swarm per 12 ore consecutive. I numeri parlano chiaro:

58.6% su SWE-Bench Pro
66.7% su Terminal-Bench 2.0
+50% sul benchmark interno Next.js di Vercel

È questo il modello che OpenClaw ora assegna di default a chiunque usi Moonshot.

Sul fronte modelli: thinking.keep = "all" è ora supportato specificamente su K2.6, e viene rimosso per gli altri modelli Moonshot quando tool_choice è pinned. Il pricing tiered dai cataloghi cached è ora supportato, con costi stimati per K2.6/K2.5 inclusi nei report token-usage.

Il lavoro infrastrutturale di cui nessuno parla

Il thread Reddit sorvola sui cambiamenti strutturali, ma sono probabilmente più importanti per la stabilità a lungo termine:

Separazione stato cron - jobs-state.json si stacca da jobs.json. Le definizioni git-tracked restano stabili mentre lo stato esecutivo muta. Se i vostri cron job sono mai driftati misteriosamente tra installazioni, questo lo risolve.
Session maintenance aggressiva - Entry cap e age prune applicati di default; store oversized potati al caricamento. Previene direttamente l’OOM del gateway da backlog di sessioni cron/executor, un problema silenzioso per gli utenti pesanti.
Notifiche di compaction - Notifiche opt-in a inizio e fine compaction del contesto. Piccolo win di UX, ma se avete mai visto il vostro agent sparire per 30 secondi chiedendovi se è crashato, le apprezzerete.
System prompt per gruppo in BlueBubbles - Istruzioni comportamentali per gruppo (convenzioni tapback, threaded-reply) iniettate ad ogni turno tramite GroupSystemPrompt, con fallback wildcard *. Chiude #60665.
Prompt GPT-5 rafforzato - Bias al completamento più netto, recovery da risultati deboli, verifica prima della risposta finale nell’overlay di sistema.
Draft streaming su Mattermost - Thinking, tool activity e reply parziali finiscono in un singolo post draft che si finalizza in-place. UX pulita per gli utenti Mattermost.
Ciclo di vita task detached - Nuovo contratto di runtime per i plugin, così gli executor possono gestire il ciclo di vita e la cancellazione dei task detached senza intaccare i core internals.

Fix che il thread Reddit non ha citato: la 4.20 porta anche diversi fix significativi. Il bug di scoping dell’API Anthropic è stato corretto: api: "anthropic-messages" ora defaulta solo su provider di proprietà Anthropic, quindi OpenAI Codex e altri provider senza api esplicito non vengono più silenziosamente riscritti sul transport sbagliato (#64534). È stato aggiunto un guard SSRF sui path di upload diretto di QQBot. Il gateway ora enforce allowRequestSessionKey sulle session key mappate via template. E la normalizzazione del transport Codex risolve gli override legacy openai-completions sugli host OpenAI/Codex di default, lasciando intoccati i proxy personalizzati.

4.21: GPT Image 2 e il secondo fix di auth in due mesi

La 4.21 è chirurgica. Il cambiamento più visibile è OpenAI Image 2 come provider di default per la generazione immagini, con hint 2K/4K nei metadata. GPT Image 2 è uscito il 21 aprile 2026 e ha raggiunto il #1 sulla Image Arena leaderboard in 12 ore, battendo tutti gli altri modelli in ogni categoria. Farlo diventare il default di OpenClaw è la scelta giusta.

Ma il cambiamento importante è il fix di auth.

È la seconda escalation di privilegio sui comandi owner che OpenClaw rattoppa in due mesi. La prima, GHSA-r7vr-gr74-94p8, è stata corretta nella 2026.3.12: sender non-owner che erano command-authorized potevano raggiungere /config e /debug. Ora #69774 chiude un gap diverso ma correlato: quando enforceOwnerForCommands=true e commands.ownerAllowFrom non è impostato, un allowFrom wildcard sul canale o una lista owner-candidate vuota venivano trattati come permesso sufficiente per i comandi owner-only. In parole povere: chiunque su un canale con configurazione permessiva poteva eseguire comandi owner. Il fix richiede un’effettiva identità owner (match su owner-candidate o operator.admin) invece di fallback su default permessivi.

È un pattern che merita attenzione. Il modello di permessi di OpenClaw continua a produrre edge case in cui il “fallback permessivo” concede silenziosamente più accesso del previsto. Ogni fix stringe il confine, ma il fatto che continui a succedere suggerisce che il layer di autorizzazione abbia bisogno di un audit più sistematico piuttosto che fix puntuali.

Altri fix della 4.21:

openclaw doctor ora recupera le dipendenze runtime mancanti di canali/provider dai path doctor senza reinstallare tutto (risponde direttamente alla regressione grammy/Telegram della 4.20)
I provider image falliti vengono loggati a livello warn prima del fallback automatico
Gli alias di thread Slack vengono preservati nelle inviate runtime generiche
I ref accessibility invalidi del browser in act vengono rifiutati subito invece di aspettare il timeout
L’alias node-domexception viene mirrorsato negli overrides di root package.json per bloccare la catena deprecata google-auth-library → gaxios → node-fetch → fetch-blob → node-domexception

I danni: cosa si è rotto con la 4.20

Il thread su r/myclaw è il solito mix di orrore e rassegnazione.

u/Acceptable-Tie278 ci ha rimesso pesante: “2026.4.20 broke my whole setup! Deleted my model api keys removed discord and my iMessage just frucked it 🤦‍♂️”

Tre subsystem morti in un aggiornamento. Il poster originale u/lucienbaba se la ride: “Not even surprised at this point. I just cope by telling myself this is the cost of innovation ;)”

u/ScroogeCa aspetta: “Thank you for beta testing, think I’ll wait for 4.21”. u/thesongofthunder lo corregge: “You mean you’ll wait for 4.22 since 4.20 and 4.21 dropped almost instantly”. Giusto, considerando che la 4.21 è letteralmente l’hotfix per i danni della 4.20.

u/CM0RDuck fa la domanda vera: “Do you people not back up anything?”

u/joaquindlz (in spagnolo) riporta zero problemi: “Yo le pedí a OC que me actualice a la 4.20 y lo hizo perfecto sin romper nada.” I danni non sono uniformi: dipendono fortemente dalla vostra configurazione specifica, dal metodo di installazione e dai canali che usate.

u/fernfahrer segnala che l’invio di file su Telegram si è rotto. u/Solotonium offre un workaround per i problemi Telegram che risalgono alla 4.9: chiedere alla TUI di OpenClaw di controllare il source code per lo schema Telegram e suggerire modifiche al vecchio openclaw.json.

Il bug grammy è reale e documentato. L’issue #69837 conferma che l’aggiornamento alla 4.20 via openclaw update rompe il runtime bundled di Telegram perché grammy diventa irrisolvibile. I file dell’estensione Telegram lo importano, il package metadata lo dichiara come dipendenza, ma dopo l’update l’installazione globale non lo trova a runtime. Il workaround è installare manualmente grammy@1.42.0 e affini dentro la directory del pacchetto openclaw, ma openclaw update ricrea il problema ad ogni esecuzione. È esattamente il tipo di regressione di packaging che il fix del doctor nella 4.21 affronta parzialmente, anche se il problema sottostante delle dipendenze runtime bundled che si perdono durante gli update resta sistematico.

Le API key che spariscono sono un pattern diverso ma correlato. Tipicamente accade quando il wizard di onboarding o la migrazione del file di configurazione sovrascrivono sezioni esistenti di openclaw.json. Il fix del doctor della 4.21 per le dipendenze plugin non lo risolve. Inoltre, il fix di sicurezza auth/commands (#69774) significa che parte della “rottura” potrebbe essere in realtà il nuovo comportamento più restrittivo che correttamente rifiuta configurazioni precedentemente permessive ma sempre state insicure.

Per chi vuole approfondire

Da qui in poi si entra nel tecnico. Se ti interessa l’idea più dell’implementazione, puoi saltare direttamente alla conclusione.

Dettagli tecnici su Kimi K2.6

Kimi K2.6 è un modello MoE con 1T di parametri totali, 384 expert, 32B attivi per token. La finestra di contesto è 262K token con compressione automatica del contesto. Supporta swarm fino a 300 sub-agent con 4.000 step in un singolo workflow per 12 ore consecutive.

Il pricing tiered nei cataloghi cached significa che i report token-usage ora includono costi stimati differenziati per K2.6 e K2.5, con il costo per token che varia in base al tier di utilizzo.

Dettagli tecnici sul fix di auth

La vulnerabilità #69774 riguarda la logica di fallback nel sistema di autorizzazione dei comandi. Quando enforceOwnerForCommands=true:

Senza il fix: un allowFrom wildcard (*) sul canale, o una lista owner-candidate vuota, venivano trattati come autorizzazione sufficiente per comandi owner-only
Con il fix: è richiesta un’effettiva identità owner, verificata tramite match su owner-candidate o appartenenza a operator.admin

Il fix precedente (GHSA-r7vr-gr74-94p8, corresse nella 2026.3.12) chiudeva un vettore diverso: sender non-owner command-authorized che potevano raggiungere /config e /debug. Il pattern ricorrente suggerisce che il layer di autorizzazione beneficerebbe di un audit sistematico.

Il punto

Punti chiave:

Kimi K2.6 come default è una scelta solida: modello agentic maturo con numeri che contano
La 4.20 porta lavoro infrastrutturale importante ma rompe Telegram e fa sparire API key in alcune configurazioni
La seconda vulnerabilità di auth in due mesi segnala un problema strutturale nel modello di permessi, non un incidente isolato
Aggiornare senza backup del openclaw.json e senza verificare grammy dopo l’update è un azzardo

La tassa OpenClaw sull’aggiornamento è diventata prevedibile: feature solide sulla carta, regressioni nella pratica, hotfix entro 24 ore. Il pattern si ripete abbastanza da meritare un workflow di update difensivo, non solo fiducia nel changelog.