OpenAI Codex 0.159.0 rende il controllo durante l’esecuzione l’elemento centrale
OpenAI Codex 0.159.0 introduce un modo opzionale per reindirizzare un agente attivo prima che termini la risposta corrente o un comando di lunga durata. Può sembrare una modifica circoscritta dell’interfaccia. In realtà affronta uno dei problemi più difficili del coding con agenti: correggere una direzione sbagliata senza scartare il lavoro utile.
La release è arrivata il 29 settembre 2026, con sei gruppi di funzionalità e un’ampia raccolta di correzioni. La sua principale novità, instant_interrupt, consente a un nuovo input di anticipare le risposte del modello e di far restituire anticipatamente alcune chiamate in modalità codice. La modalità codice è il percorso di esecuzione di Codex per avviare comandi e attendere processi in corso.
Questo colloca Codex in una competizione diretta sull’interazione con GitHub Copilot CLI e altri agenti di coding. La sfida non riguarda più soltanto quale modello scriva la patch più solida. Sempre più spesso riguarda quale agente resti comprensibile, guidabile e recuperabile mentre il lavoro reale è in corso.
Cosa cambia davvero con OpenAI Codex 0.159.0
La release tratta il controllo dell’agente come un’interazione continua, non come una sequenza di prompt isolati.
La release di Codex è incentrata su instant_interrupt, sebbene il flag resti disabilitato per impostazione predefinita. Quando è abilitato, un nuovo input dell’utente può guidare Codex durante una risposta del modello. Può inoltre influire su chiamate exec e wait di lunga durata in modalità codice.
In precedenza, l’input inviato durante una di queste chiamate poteva restare in coda fino al loro completamento. Il comportamento è prevedibile, ma crea un ritardo costoso quando l’utente individua un presupposto errato. L’agente potrebbe continuare a eseguire test, generare output o seguire un percorso d’implementazione sbagliato prima di leggere la correzione.
Il nuovo meccanismo monitora l’input in coda durante ogni richiesta di campionamento. Trasmette quindi un segnale di preemption condiviso alle chiamate di strumenti idonee. Una cella in esecuzione può restituire il proprio identificatore senza essere terminata, consentendo a Codex di elaborare la nuova istruzione.
Questa distinzione conta. Restituire anticipatamente il controllo non equivale a terminare il comando. Il lavoro sottostante può continuare, mentre una successiva chiamata wait ne raccoglie i risultati. Codex ottiene l’opportunità di riconsiderare la prossima azione senza distruggere automaticamente uno stato di esecuzione utile.
La modifica complementare alle risposte del modello completa il ciclo. Un nuovo input può anticipare la risposta in fase di generazione, anziché attendere dietro di essa. La release conserva inoltre messaggi in coda e risultati degli strumenti lungo il percorso d’interruzione.
Si consideri uno sviluppatore che chiede a Codex di ristrutturare un servizio di autenticazione. Mentre l’agente esegue i test, lo sviluppatore nota che un client meno recente dipende ancora dal formato esistente dei token. Con l’interruzione istantanea abilitata, questo vincolo può raggiungere Codex prima che completi il piano originale.
La release include diverse modifiche minori dell’interfaccia che sostengono lo stesso tema. Le nuove sessioni mostrano una schermata di benvenuto più compatta e utilizzano intestazioni coerenti, senza bordi. I suggerimenti possono comparire durante il lavoro attivo e dopo la conclusione di un turno.
Il visualizzatore degli avvisi ora rimuove gli avvisi che l’utente ha esaminato prima di chiuderlo. Premendo k si mantiene un avviso selezionato per un secondo momento. Questo trasforma il visualizzatore in una coda leggera di triage anziché in un elenco che richiede ispezioni ripetute.
Gli utenti possono inoltre scorrere la trascrizione mentre rimane aperta una finestra di dialogo per l’implementazione di un piano. Ciò consente un modello di revisione semplice ma importante: rileggere le evidenze prima di autorizzare le modifiche proposte.
Nel loro insieme, queste funzionalità di Codex 0.159.0 riducono l’attrito dell’interfaccia attorno alle lunghe sessioni con agenti. La release non annuncia un nuovo modello di coding. Cambia la rapidità con cui un essere umano può influenzare il modello già al lavoro.
Instant Interrupt cambia il costo di una correzione
Guidare l’agente durante l’esecuzione conta perché una correzione precoce è di norma meno costosa della revisione di un errore completato.
Un agente di coding non passa direttamente dal prompt alla patch finita. Esamina i file, elabora un piano, richiama strumenti, legge i risultati, modifica il codice e convalida tali modifiche. Un presupposto errato può propagarsi in ogni fase.
Le interfacce chat tradizionali collocano i nuovi messaggi dietro la risposta corrente. Questo ordinamento funziona per domande con risposte brevi. Diventa limitante quando un agente esegue comandi che richiedono diversi minuti o attende processi con tempi di completamento incerti.
L’implementazione del rilascio del controllo di OpenAI affronta questo ritardo senza presumere che ogni nuovo messaggio debba annullare il lavoro corrente. La cella attiva restituisce il controllo, ma continua a essere eseguita. Codex può quindi incorporare la nuova istruzione e decidere come procedere.
Questo crea una via intermedia tra attendere e interrompere. L’attesa conserva il lavoro ma ritarda la correzione. L’interruzione risponde immediatamente ma può sprecare l’avanzamento dell’esecuzione o lasciare l’utente incerto su ciò che si è fermato.
Il design dell’interruzione istantanea di Codex mira a preservare sia la reattività sia la continuità. È il meccanismo centrale della release, ed è più significativo di un’altra scorciatoia o di un aggiornamento visivo.
La funzionalità ha anche implicazioni per il lavoro sensibile alle autorizzazioni. Un utente può aggiungere un vincolo quando la direzione emergente dell’agente diventa visibile. Per esempio, l’utente potrebbe vietare una dipendenza, limitare le modifiche a un solo pacchetto o richiedere la retrocompatibilità.
Tale intervento dipende comunque dalla tempistica. Un messaggio non può annullare un effetto collaterale esterno che si è già verificato. Non sostituisce neppure controlli di approvazione accurati per i comandi con conseguenze rilevanti.
L’interruzione istantanea riduce invece l’intervallo tra il riconoscimento di un problema e la possibilità di influenzare l’agente. Questa finestra più stretta diventa preziosa man mano che i compiti di coding si allungano e includono più chiamate di strumenti.
Lo stato opzionale merita attenzione. OpenAI non presenta questo comportamento come un’impostazione predefinita universale. La preemption modifica l’ordinamento dei messaggi, i tempi di esecuzione e le aspettative degli utenti, quindi un’adozione prudente è ragionevole.
Gli utenti devono anche comprendere cosa significhi “interruzione” in questo contesto. La cella attiva in modalità codice può continuare dopo aver restituito il controllo. Chi si aspetta un arresto d’emergenza potrebbe interpretare male tale comportamento, a meno che l’interfaccia non comunichi chiaramente lo stato della cella.
La modifica alla preemption delle risposte copre un’altra parte dell’esperienza. L’input in arrivo può interrompere l’attuale risposta del modello e guidare il turno in corso. Il sistema considera anche i messaggi che arrivano durante la compattazione del contesto.
La compattazione riassume il contesto precedente della sessione quando la conversazione diventa ampia. L’input che arriva durante questo processo deve essere rinviato e conservato, anziché perso o applicato in un ordine incoerente.
Questi dettagli rivelano la difficoltà dietro una funzionalità apparentemente semplice. Non basta una casella di testo reattiva. La guida deve coordinare generazione del modello, input in coda, esecuzione in background, risultati degli strumenti e cronologia della conversazione.
OpenAI Codex 0.159.0 rappresenta quindi più un aggiornamento dell’orchestrazione che un aggiornamento dell’intelligenza. Rende il ciclo dell’agente più interrompibile cercando al contempo di conservare il lavoro che rimane utile.
Gli agenti di coding competono sul controllo, non solo sull’output
La sfida principale si sta spostando dal completamento autonomo verso una collaborazione utile durante l’esecuzione.
GitHub documenta una distinzione simile tra guida e accodamento nei suoi prodotti per agenti di coding. Un messaggio di guida modifica il lavoro corrente, mentre un messaggio in coda attende il turno successivo.
Nelle sessioni cloud agent di GitHub Copilot, la guida di follow-up viene applicata dopo il completamento della chiamata allo strumento corrente. I controlli di sessione di GitHub espongono inoltre l’avanzamento in tempo reale, i log della sessione, l’arresto e l’archiviazione.
GitHub Copilot CLI si spinge oltre nella sua interfaccia locale. Un semplice messaggio inserito mentre l’agente sta elaborando diventa, per impostazione predefinita, input di guida. Gli utenti possono invece accodare separatamente il lavoro per un turno successivo.
L’implementazione di OpenAI differisce sotto un aspetto importante. Il suo percorso opzionale consente alle chiamate idonee di lunga durata in modalità codice di restituire il controllo prima della conclusione del processo sottostante. Questo può ridurre il ritardo tra l’intervento dell’utente e la riconsiderazione da parte del modello.
Ciò non dimostra che un prodotto sia categoricamente più veloce o più sicuro dell’altro. La release non contiene un confronto indipendente della latenza, un benchmark di completamento o una riduzione misurata del lavoro sprecato. Qualunque conclusione più ampia sulle prestazioni sarebbe prematura.
Mostra però dove si sta dirigendo la competizione tra agenti di coding. La qualità del modello resta importante, ma la differenziazione pratica deriva sempre più dal controllo del lavoro già in corso.
Un agente solido può comunque diventare frustrante quando nasconde lo stato, ritarda le correzioni o impone un annullamento tutto-o-niente. Anche un modello più debole può consumare molto tempo se l’utente non riesce a reindirizzarlo prima che un errore si ampli.
L’interazione desiderata assomiglia più al pair programming che a una coda di lavori. Un partecipante avvia un approccio, mentre l’altro può aggiungere vincoli man mano che emergono le evidenze. Nessuno dei due deve riavviare l’intero compito dopo ogni correzione.
Questo schema influisce anche sulla valutazione aziendale. I team devono sapere se gli sviluppatori possono ispezionare il lavoro attivo, comprendere le operazioni in attesa e intervenire prima che un agente oltrepassi un confine del progetto.
La verificabilità diventa parte del prodotto. Lo stesso vale per la distinzione tra aggiungere contesto, cambiare direzione, accodare un’altra attività e arrestare l’esecuzione. Queste azioni non dovrebbero apparire identiche perché le loro conseguenze sono diverse.
Le modifiche relative agli avvisi, all’accesso alla trascrizione e alla presentazione delle sessioni supportano questo requisito. Offrono agli utenti più informazioni mentre una decisione resta aperta, invece di presentare soltanto un risultato completato.
Questo modello d’interazione premia anche un buon contesto di progetto. La guida funziona meglio quando l’utente può fornire un vincolo preciso supportato dalla documentazione esistente. Una base di conoscenza ricercabile può aiutare i team a recuperare tali vincoli prima di approvare il piano di un agente.
OpenAI Codex 0.159.0 non risolve la sfida del controllo. Stabilisce una direzione di prodotto più chiara: un agente dovrebbe restare reattivo anche quando i suoi strumenti sono occupati.
Le funzionalità minori rendono più facili da leggere le sessioni lunghe
Le modifiche all’interfaccia riducono il carico cognitivo nei momenti in cui gli utenti devono esaminare, approvare o conservare informazioni.
La nuova schermata di sessione è più compatta e le intestazioni delle sessioni seguono ora un design coerente senza bordi. Queste modifiche non alterano la generazione di codice, ma riducono la variazione visiva nell’interfaccia del terminale.
Suggerimenti occasionali compaiono ora mentre Codex lavora e dopo il completamento dei turni. Questo può rendere disponibili controlli utili quando gli utenti ne hanno bisogno, anche se le indicazioni ricorrenti devono evitare di diventare un’ulteriore fonte di rumore.
Il flusso di lavoro degli avvisi riceve una modifica più funzionale. La chiusura del visualizzatore rimuove gli avvisi che l’utente ha già esaminato. Un’azione mantieni-e-successivo, attivata con k, conserva un avviso importante e fa avanzare la selezione.
Questo design associa gli avvisi a un modello familiare di posta in arrivo. Gli elementi esaminati escono dalla coda attiva, mentre le eccezioni restano disponibili. La modifica dovrebbe ridurre le scansioni ripetute durante le sessioni che producono diversi avvisi.
La trascrizione può ora rimanere scorrevole mentre una finestra di dialogo modale chiede se Codex debba implementare un piano. In precedenza, una finestra modale poteva limitare la capacità dell'utente di tornare alla discussione precedente proprio nel momento in cui la revisione era più importante.
L'approvazione di un piano non è un clic cerimoniale. Una decisione utile può richiedere di verificare la richiesta originale, l'output precedente degli strumenti, i rischi identificati e le ipotesi dichiarate dall'agente. L'accesso alla trascrizione rende più facile questo confronto.
Anche la copia di contenuti dalla trascrizione è più affidabile. Le selezioni conservano tabelle Markdown, formattazione e spazi bianchi significativi, mentre ulteriori ambienti terminali supportano il comportamento di copia automatica alla selezione.
Questa correzione è importante quando gli utenti trasferiscono l'output generato in sistemi di tracciamento dei problemi, revisioni del codice, documentazione o registri degli incidenti. La perdita di formattazione può cambiare il significato di log, tabelle e testo adiacente al codice.
Il rendering nativo di Mermaid riceve un supporto sintattico più ampio. Mermaid è un linguaggio di diagrammi basato su testo che descrive flussi e relazioni attraverso codice sorgente compatto.
Il renderer aggiornato preserva punteggiatura e punti e virgola nelle etichette. Riconosce inoltre più relazioni nei diagrammi di flusso, etichette dei collegamenti, indicatori di direzione e strutture di nodi raggruppati.
Questo trasforma i diagrammi di architettura generati dagli agenti in artefatti terminali più utili. Uno sviluppatore può chiedere a Codex di spiegare il flusso di un servizio, ispezionare il risultato renderizzato e conservare comunque il codice sorgente Mermaid sottostante.
L'aggiornamento di Mermaid evidenzia anche una sfida ricorrente dell'interfaccia. I diagrammi generati sono utili solo quando il renderer accetta la sintassi che i modelli producono comunemente.
I client app-server ottengono una funzionalità di livello inferiore con la paginazione dei thread ancorata agli elementi. Un client può richiedere la cronologia del thread in relazione a un elemento specifico, anziché navigare solo attraverso pagine più ampie.
Questo dovrebbe aiutare le applicazioni a caricare la parte rilevante di una conversazione lunga. Offre inoltre agli sviluppatori client un maggiore controllo su timeline riprendibili e viste incrementali della cronologia.
Nessuna di queste aggiunte ha il peso concettuale dell'interruzione istantanea. Nel complesso, tuttavia, rendono le sessioni estese più facili da avviare, ispezionare, navigare e riutilizzare.
Questo conta perché l'usabilità degli agenti peggiora quando le conversazioni crescono. Modelli migliori da soli non risolvono la navigazione della trascrizione, l'affaticamento da avvisi, i fallimenti dei diagrammi o la perdita di formattazione.
Le correzioni per Windows e Sandbox hanno il peso operativo
La release colma anche lacune di piattaforma e sicurezza che possono contare più dei miglioramenti visibili dell'interfaccia.
Su Windows, Codex ora sopprime le finestre della console indesiderate all'avvio di vari tipi di processi figlio. I percorsi interessati includono server locali Model Context Protocol, host in code-mode e comandi collegati tramite pipe.
MCP è un protocollo per collegare i modelli a strumenti e fonti di dati esterni. Un server MCP locale può essere eseguito come processo figlio in background, quindi una finestra della console inattesa può interrompere l'esperienza desktop.
I launcher Windows restrittivi possono ora ripiegare sulla modalità incorporata. Ciò fornisce un'altra via di esecuzione quando le regole di creazione dei processi impediscono il funzionamento dell'architettura preferita.
La release migliora anche il comportamento di avvio dei daemon in presenza di appartenenza residua a Windows job. Un'altra correzione impedisce che gli handle di input e output del launcher restino collegati dove non dovrebbero.
Questi cambiamenti riguardano l'affidabilità piuttosto che il comportamento del modello. Sono particolarmente rilevanti per macchine gestite, integrazioni desktop e flussi di lavoro terminali che creano più sottoprocessi.
I confini di sicurezza ricevono un'attenzione separata. I comandi approvati ora mantengono i rifiuti espliciti di accesso al filesystem invece di perdere tali restrizioni durante la preparazione del comando.
Codex protegge inoltre per impostazione predefinita le directory .aws quando compaiono sotto root scrivibili. Tali directory possono contenere configurazioni o credenziali cloud, rendendo significativo questo confine predefinito.
La release non sostiene che questi cambiamenti eliminino il rischio della sandbox. Indica però che OpenAI sta rafforzando il passaggio tra l'approvazione dell'utente e i permessi applicati durante l'esecuzione.
Questo confine merita attenzione perché un comando approvato non equivale a un accesso illimitato al filesystem. Se la preparazione del comando scarta un rifiuto esplicito, il runtime non riflette più la decisione esaminata dall'utente.
Le sandbox macOS abilitate alla rete ricevono una correzione della fiducia TLS. L'aggiornamento consente la valutazione della fiducia di sistema nei profili Seatbelt pertinenti, ovvero le policy sandbox di macOS che limitano le capacità dei processi.
Anche gli ambienti remoti che richiedono un proxy ottengono un comportamento di esecuzione corretto. Queste correzioni affrontano lacune comuni tra l'accesso di rete nominale di uno strumento di sviluppo e le regole della macchina che lo ospita.
Anche l'autenticazione diventa meno fragile. I flussi app-server locali dovrebbero aprire più affidabilmente il browser per l'accesso a ChatGPT. L'onboarding ora offre una scorciatoia per copiare l'URL di login quando l'apertura automatica non è adatta.
Le sessioni vuote conservano le bozze quando gli utenti cambiano attività. I thread possono essere archiviati ed elencati prima che contengano un primo turno completato, rendendo la gestione delle sessioni meno dipendente dallo stato della conversazione.
Queste correzioni rafforzano la direzione più ampia della release. Gli agenti a esecuzione prolungata necessitano di stato durevole e comportamento prevedibile dei processi, non solo di risposte impressionanti.
Un agente di coding che apre finestre indesiderate, perde bozze, gestisce male i rifiuti o non funziona dietro un proxy impone costi operativi. Tali fallimenti possono ostacolare l'adozione anche quando il codice generato è accettabile.
Lo steering opt-in necessita ancora di una prova nel mondo reale
Il valore della funzionalità dipende da tempi prevedibili, chiari indicatori di stato e comportamento corretto sotto pressione.
La prima incertezza è la latenza. La release spiega che le chiamate idonee possono cedere il controllo quando arriva un nuovo input, ma non pubblica misurazioni dei tempi. Gli utenti devono ancora osservare con quale rapidità lo steering abbia effetto.
La seconda incertezza riguarda la semantica. “Interrupt”, “preempt”, “yield” e “stop” descrivono operazioni diverse. Un processo in esecuzione può sopravvivere dopo che Codex cede il controllo, mentre un utente potrebbe presumere che il lavoro sia terminato.
Un'interfaccia chiara dovrebbe rivelare se un processo rimane attivo, se il suo output continua ad arrivare e se l'agente intende consultare quell'output. L'ambiguità in questo punto può creare comandi duplicati o modifiche in conflitto.
La terza questione è l'adozione. Poiché instant_interrupt è disabilitato per impostazione predefinita, il suo impatto iniziale sarà limitato agli utenti che scoprono e abilitano il flag.
Un rilascio opt-in lascia spazio ai test, ma restringe anche il feedback disponibile. Gli utenti esperti potrebbero usare la funzionalità in modo diverso rispetto agli sviluppatori che incontrano il coding agentico per la prima volta.
La quarta questione riguarda le race condition. Un nuovo input può arrivare durante la generazione del modello, l'esecuzione, l'attesa o la compattazione del contesto. Ogni percorso deve preservare l'ordine dei messaggi e impedire che i risultati degli strumenti vengano associati al passaggio di ragionamento sbagliato.
OpenAI afferma che i suoi test coprono il comportamento abilitato e disabilitato, lo steering ripetuto, l'input differito durante la compattazione e le chiamate successive nella stessa risposta. I test verificano inoltre che i messaggi in coda e i risultati diretti degli strumenti restino preservati.
Questi casi sono necessari, ma le sessioni di produzione generano combinazioni meno ordinate. Uno sviluppatore potrebbe effettuare steering ripetutamente, modificare l'ambito dei file richiesti, rifiutare un'autorizzazione e ricevere output di processo tardivo in un unico turno.
La quinta questione è la sicurezza. Uno steering più rapido può aiutare a fermare un errore in corso, ma non sostituisce l'approvazione dei comandi, le restrizioni della sandbox o la revisione del repository.
Un comando dannoso può completarsi prima che arrivi la correzione. Un servizio esterno potrebbe inoltre elaborare una richiesta anche dopo che l'agente locale ha cambiato direzione. Gli utenti non dovrebbero trattare l'interruzione conversazionale come un rollback transazionale.
Esiste anche il rischio di uno steering eccessivo. Correzioni frequenti possono produrre un obiettivo frammentato, soprattutto quando l'agente conserva il contesto precedente e diverse istruzioni competono per priorità.
I team avranno bisogno di convenzioni di interazione. Un messaggio di steering dovrebbe indicare chiaramente cosa è cambiato, quale istruzione precedente sostituisce e se l'esecuzione corrente debba continuare.
La rimozione dei suggerimenti automatici per prompt di follow-up è rilevante in questo contesto. Codex 0.159.0 rimuove sia tali suggerimenti sia l'impostazione correlata. OpenAI sembra ridurre l'impalcatura di prompt non richiesta, aggiungendo al contempo un controllo utente più diretto.
La release rimuove anche la skill plugin-creator inclusa nel pacchetto. Questo cambiamento di packaging non va confuso con la funzionalità di steering, ma gli utenti che si affidano alle capacità incluse dovrebbero rivedere la propria configurazione locale dopo l'aggiornamento.
L'interpretazione scettica è semplice. OpenAI ha aggiunto il meccanismo per un intervento più rapido, ma la release non fornisce prove che migliori i tassi di successo delle attività.
Questo non rende la funzionalità poco importante. Definisce la prossima domanda di valutazione: lo steering a metà esecuzione evita abbastanza lavoro sprecato da giustificare la complessità aggiuntiva dell'esecuzione?
Tre segnali da osservare dopo Codex 0.159.0
Il prossimo test è capire se l'interruzione istantanea passerà da controllo sperimentale a componente affidabile del coding quotidiano.
Il primo segnale è lo stato predefinito. Se OpenAI abilita instant_interrupt per impostazione predefinita in una release successiva, ciò indicherebbe fiducia nell'ordinamento, nella preservazione e nella chiarezza dell'interfaccia.
Mantenerlo opt-in per diverse release suggerirebbe che i casi limite necessitano ancora di attenzione. Potrebbe anche significare che OpenAI desidera un consenso esplicito per un comportamento che modifica le aspettative consolidate sulle code.
Il secondo segnale è l'attività relativa a issue e release riguardo allo steering ripetuto. Segnalazioni che coinvolgono messaggi persi, comandi duplicati, processi orfani o output tardivo indebolirebbero la tesi a favore dell'interruzione immediata.
Le correzioni che ampliano i percorsi degli strumenti supportati la rafforzerebbero. Il design attuale riguarda specificamente le risposte del modello e le chiamate exec o wait a lunga esecuzione in code-mode, non ogni possibile operazione esterna.
Il terzo segnale è il comportamento dei concorrenti. GitHub documenta già sia lo steering immediato sia i follow-up in coda attraverso i suoi prodotti e SDK. Altri fornitori di coding agent affrontano la stessa pressione per esporre controlli chiari durante l'esecuzione.
Il confronto importante non sarà se i prodotti contengano una funzionalità chiamata steering. Sarà quanto rapidamente una correzione abbia effetto e con quanta accuratezza il sistema spieghi lo stato dell'esecuzione rimanente.
Gli sviluppatori dovrebbero testare OpenAI Codex 0.159.0 su attività circoscritte e reversibili prima di affidarsi all'interruzione durante lavori sensibili. Una prova utile potrebbe prevedere una lunga esecuzione di test, una correzione dell'ambito e l'ispezione del processo sopravvissuto.
Verificate se Codex riceve prontamente la nuova istruzione. Confermate se il processo originale rimane attivo. Poi verificate che l'output successivo sia associato al turno corretto e non riattivi l'approccio abbandonato.
La release esprime un giudizio di prodotto persuasivo: gli utenti necessitano di un modo per intervenire prima che un agente finisca di sbagliare. L'implementazione deve ora dimostrare che un intervento più rapido resta comprensibile sotto carichi di lavoro reali.
Se abilitate OpenAI Codex 0.159.0, iniziate con una domanda pratica. Potete reindirizzare un'attività lunga senza perdere progressi utili né diventare incerti su cosa sia ancora in esecuzione? Questo risultato conta più del flag stesso.
