Claude Code in un container: cosa non vede dell'ambiente in cui gira

Claude Code in un container è una sessione dell'agente che gira dentro un ambiente isolato, con CPU, memoria e rete limitate dall'esterno, e quasi sempre senza nessuno davanti al terminale. La versione 2.1.229, pubblicata sul changelog ufficiale di Claude Code il 12 agosto 2026, corregge un bug che riguarda esattamente questo scenario: dentro un container con un limite di CPU, i workflow dinamici contavano i core della macchina ospite invece del limite imposto al container.

Tradotto in pratica, un fan-out dimensionato su una macchina da molti core partiva identico anche quando il container ne aveva due veri a disposizione. Non è un dettaglio da nota a piè di pagina, ed è il motivo per cui vale la pena guardare questa versione con attenzione se Claude Code lo fate girare in Docker, in una pipeline di CI o su un runner con una quota di risorse.

Perché il numero di core è il dettaglio che rompe di più

Un agente che legge il numero di core sbagliato non si ferma con un errore: rallenta. È questa la ragione per cui un bug del genere sopravvive a lungo senza che nessuno lo apra come segnalazione. La sessione finisce lo stesso, il risultato è corretto, e l'unica traccia è un tempo di esecuzione che sembra semplicemente il tempo che ci vuole. Chi guarda il log vede un lavoro andato a buon fine, non un lavoro che ha aspettato in coda il triplo del necessario.

La correzione della 2.1.229 mette il conteggio dove doveva stare, cioè sul limite di CPU del container. Nella stessa versione Anthropic ha aggiunto anche uno sfalsamento dei fan-out: gli agenti fratelli che condividono lo stesso prefisso di prompt partono scaglionati, così quelli successivi leggono il prefisso già in cache invece di ripagarlo. Chi ha un motivo per non volerlo può disattivarlo con la variabile d'ambiente CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS=0, che è esattamente il tipo di dettaglio concreto che serve avere sottomano quando si sta debuggando un costo che non torna.

C'è un secondo posto in cui l'ambiente non interattivo si fa sentire. La 2.1.229 corregge un crash di tipo RangeError che scattava quando una barra di avanzamento o una tabella markdown venivano disegnate in una finestra di terminale molto stretta, e che poteva far fallire anche claude --continue e claude --resume all'avvio. Una finestra stretta non è un caso di laboratorio: è la larghezza di colonna che si ritrova un job in CI.

Le tre cose che fermavano un runner self-hosted all'avvio

La versione 2.1.229 di Claude Code corregge tre modi diversi in cui una sessione su runner self-hosted moriva o si piantava prima ancora di iniziare a lavorare, e sono tre modi che hanno la stessa forma: qualcosa che su una macchina con una persona davanti si risolve in due secondi, e senza quella persona non si risolve mai.

Il primo riguarda managed-mcp.json. Quando quel file era distribuito sul runner e insieme il server consegnava i propri server MCP, le sessioni self-hosted e le altre sessioni remote uscivano all'avvio. Adesso quei server vengono saltati con un avviso invece di far terminare la sessione. Il secondo è la preparazione del repository che restava appesa a un prompt di Git Credential Manager: git ora fallisce subito quando le credenziali mancano, invece di aspettare una risposta che in un container non arriverà mai. Il terzo è un cambio di comportamento e non una correzione, quindi va letto prima di aggiornare: l'avvio del runner self-hosted su Windows adesso richiede un --base-dir esplicito, perché su Windows non esiste una cartella di checkout predefinita.

Nella stessa direzione va una novità vera: le sessioni su runner self-hosted ora supportano gli hook forniti dal server, allineandosi al comportamento degli ambienti gestiti. E per le connessioni lunghe la 2.1.229 aggiunge ping di keepalive SSE alle risposte in streaming del gateway, che servono a evitare le disconnessioni per inattività su Vertex e Bedrock durante le pause lunghe di ragionamento. È il caso classico di una sessione automatica che muore non perché ha sbagliato qualcosa, ma perché ha pensato troppo a lungo in silenzio.

Cosa controllare prima di far girare Claude Code in un container

Da questa versione discendono quattro controlli concreti, tutti verificabili in pochi minuti sulla configurazione che avete già.

1. Il limite di CPU del container va dichiarato davvero, non lasciato implicito. La correzione della 2.1.229 fa leggere a Claude Code il limite del container, ma se quel limite non c'è l'agente continua legittimamente a vedere la macchina intera.
2. Il comando di avvio del runner self-hosted su Windows va aggiornato con --base-dir, altrimenti dopo l'aggiornamento non parte.
3. Le liste di domini della sandbox vanno riguardate se contengono indirizzi IPv6: la 2.1.229 li racchiude fra parentesi quadre nella forma [::1]:443, tratta in modo fail-closed le scritture ambigue e le segnala con /doctor. Fail-closed vuol dire che nel dubbio blocca, quindi una regola scritta male che prima passava adesso chiude il traffico.
4. Il flusso /commit-push-pr non auto-approva più i comandi git e gh con flag pericolosi come --force, --amend e --no-verify. Se avete un'automazione che contava su quell'approvazione implicita, adesso si ferma.

Il pezzo di automazione che tengo su questo sito gira esattamente in queste condizioni. Nel repository c'è .github/workflows/stato-indice.yml, un job schedulato alle 06:40 UTC che parte su ubuntu-latest, fa npm ci e controlla cosa Google ha indicizzato e cosa no; e in automazione-blog/cloud-agent/ c'è la routine che ogni mattina scrive gli articoli di questo blog mentre io non sono davanti a niente. La decisione che ho preso dentro quel workflow c'entra con la 2.1.229 più di quanto sembri: quando il secret manca il job si ferma verde invece di fallire, perché fallire tutte le mattine per una cosa che si sa già insegna soltanto a ignorare le notifiche, e il giorno che il guasto è vero non lo guarda più nessuno. È la stessa logica delle correzioni di questa versione, dove managed-mcp.json adesso produce un avviso invece di uccidere la sessione.

Sul rapporto fra automazione e permessi ho scritto più in dettaglio nell'articolo sui controlli da fare prima di far girare Claude Code in automatico, e sul comportamento della sandbox in quello sulla modalità mask e i permessi di Bash della 2.1.221. Vale la pena leggerli insieme a questa versione, perché descrivono la stessa superficie da due lati diversi.

Resta una correzione che non riguarda i container ma che merita una riga, perché tocca chiunque faccia sessioni lunghe: le conversazioni i cui soli messaggi superano il limite di 32 MB per richiesta dell'API adesso falliscono una volta sola con un messaggio chiaro, invece di continuare a ritentare la compattazione quando non ci sono immagini o documenti da togliere. E gli errori "prompt is too long" spiegano perché la compattazione automatica non è riuscita a recuperare, invece di limitarsi a suggerire /compact. Chi lavora con la memoria automatica di Claude Code e con contesti che crescono da soli sa quanto la differenza fra un errore che spiega e un errore che ripete valga in termini di tempo.

La lettura d'insieme della 2.1.229 è che Anthropic sta trattando l'esecuzione senza persona davanti come uno scenario di prima classe e non come un uso di frontiera. Le versioni precedenti avevano lavorato molto sui permessi e sull'isolamento; questa lavora sul fatto banale che un agente automatico deve sapere dove sta girando. Contare i core giusti, non aspettare una password che nessuno digiterà, morire con un avviso invece che in silenzio: sono tutte cose che contano solo quando la sedia davanti al terminale è vuota, ed è esattamente lì che sempre più gente sta mettendo Claude Code.

La fonte di tutto quanto sopra è il changelog ufficiale di Claude Code, voce 2.1.229 del 12 agosto 2026.