Copilot CLI adotta Rust e ripristina le sessioni: conta la prova di interruzione

In breve: GitHub segnala che Copilot CLI ora usa un runtime nativo Rust, mentre l’interfaccia terminale resta in TypeScript, e può ripristinare sessioni terminate in modo non corretto, incluse quelle interrotte a metà turno. La verifica sensata è interrompere un’attività controllata su un repository reale e controllare che la ripresa mantenga contesto e confini operativi senza duplicare comandi o modifiche.

Che cosa cambia nella CLI

Nel riepilogo settimanale GitHub attribuisce prestazioni più rapide al passaggio della CLI a un runtime nativo Rust. L’interfaccia del terminale rimane costruita in TypeScript, quindi l’annuncio descrive un cambiamento del runtime, non una riscrittura totale dell’esperienza.

La stessa release introduce il ripristino delle sessioni che non sono terminate correttamente, anche quando l’interruzione avviene a metà turno. È una promessa operativa precisa e quindi verificabile.

Più controlli su esecuzione e permessi

Le nuove opzioni defaultMode e defaultPermissionMode permettono di avviare le sessioni con modalità di esecuzione e permesso preferite. GitHub segnala inoltre nuove esperienze per gestire plugin, server MCP e skill tramite i rispettivi comandi della CLI.

Questi default riducono configurazioni ripetitive, ma possono anche rendere abituale un livello di accesso eccessivo. La configurazione iniziale va quindi trattata come policy, non come comodità personale.

Perché interrompere il processo è il test giusto

Una sessione agente può avere comandi in corso, modifiche non committate e decisioni già prese nel contesto. Ripristinare il testo della conversazione non basta se il sistema perde la relazione con lo stato reale del repository.

Il test dovrebbe provocare un’interruzione in un ambiente sacrificabile e poi verificare stato Git, processi, file modificati e richieste di autorizzazione. Qualsiasi azione ripetuta senza conferma è un difetto operativo, anche se l’agente produce alla fine un risultato plausibile.

Come valutare il runtime senza benchmark da vetrina

GitHub parla di prestazioni significativamente più rapide, ma l’annuncio non sostituisce una misura sul proprio repository. Tempi di avvio, reattività e stabilità vanno osservati su task identici e con la stessa configurazione.

Il criterio di adozione dovrebbe includere anche recupero, prevedibilità dei permessi e correttezza delle modifiche. Una CLI più rapida ma meno controllabile non migliora il workflow.

Checklist pratica

1. Usa un branch o repository di prova con stato noto.
2. Registra modalità di esecuzione, permessi, plugin, MCP e skill attivi.
3. Avvia un task che produca modifiche e verifiche osservabili.
4. Interrompi la sessione a metà turno senza coinvolgere dati o sistemi critici.
5. Ripristina la sessione e controlla diff, processi, log e richieste di permesso.
6. Ripeti il test con la configurazione precedente e documenta le differenze.