Codex resume: riprendere le sessioni della CLI senza ripartire da zero

🧭 Cos'è una sessione di Codex e dove vive

Una sessione di Codex CLI è la registrazione completa di una conversazione: i miei prompt, le risposte del modello, le chiamate ai tool e i loro risultati. Mentre lavoro, la CLI la scrive in continuazione in un file JSONL dentro ~/.codex/sessions/. Il salvataggio è sempre attivo: non esiste un comando per salvare, perché non serve.

Il punto importante è che la ripresa è agganciata alla cartella di lavoro: codex resume considera per default le sessioni partite dalla directory corrente. Ogni progetto ha quindi la sua storia, e quando riprendo l'ultima sessione ottengo quella di questo repo, non l'ultima cosa fatta altrove.

I punti d'ingresso sono tre: codex resume dal terminale, /resume da dentro una sessione già aperta, e codex exec resume per i run non interattivi. Li uso tutti, ma in momenti diversi della giornata.

# riapre l'ultima sessione della cartella corrente
codex resume --last

# apre il session picker interattivo
codex resume

# riprende una sessione per nome o per ID
codex resume auth-refactor

# da dentro una sessione attiva: cambia conversazione
/resume

🔁 --last, picker e ripresa per nome: come scelgo

codex resume --last è il gesto quotidiano: riapre la sessione più recente della cartella in cui mi trovo, senza ID da ricordare né domande. È l'equivalente del --continue di Claude Code, e per il lavoro su un filo solo copre il 90% dei casi.

Quando l'ultima sessione non è quella giusta, lancio codex resume senza argomenti e si apre il picker: un elenco delle sessioni recenti con data e anteprima, in cui mi muovo con le frecce e confermo con Invio. Di default vedo le sessioni della directory corrente; con --all allargo la ricerca a quelle partite da qualsiasi cartella.

Il terzo modo è la ripresa diretta: codex resume <id-o-nome> accetta sia la session ID (un UUID) sia il nome della sessione, e se l'argomento è un UUID valido vince l'ID. Il nome è anche quello che uso con codex archive, codex unarchive e codex delete per tenere in ordine l'elenco: le sessioni chiuse le archivio, quelle inutili le elimino.

📂 Cartella diversa? Il ruolo di tui.resume_cwd

Un caso che capita spesso: riprendo una sessione da una directory diversa da quella in cui era partita. Codex se ne accorge e mi chiede quale cartella usare — quella corrente o quella salvata nella sessione. È una domanda sensata, perché la cartella determina cosa il sandbox può scrivere.

Se la risposta è sempre la stessa, la fisso in config.toml con tui.resume_cwd: "current" per usare sempre la directory da cui lancio, "session" per tornare sempre a quella originale. Un'esplicita --cd (o -C) sulla riga di comando vince comunque sulla configurazione.

Dettaglio comodo: codex resume accetta gli stessi flag globali di codex, quindi posso riprendere una sessione cambiando modello o sandbox al volo — per esempio riaprire in read-only una sessione partita in workspace-write solo per farle domande.

# ~/.codex/config.toml

[tui]
# "current"  → usa la directory da cui lancio codex resume
# "session"  → torna alla directory originale della sessione
resume_cwd = "current"

🌿 codex fork e /side: sperimentare senza perdere il filo

Quando sono a un buon punto e voglio provare una strada diversa — un'altra libreria, un approccio più aggressivo — non sacrifico la conversazione che mi ci ha portato: uso codex fork, che duplica una sessione precedente in un nuovo thread lasciando il transcript originale intatto. Da dentro una sessione attiva faccio lo stesso con /fork.

Per le divagazioni brevi c'è /side: apre una conversazione laterale usa-e-getta senza abbandonare il task principale. La uso per le domande di controllo — «questo approccio ha un problema evidente?» — prima di tornare al filo principale, senza sporcare il contesto della sessione.

La distinzione da tenere a mente è la stessa di ogni strumento di questo tipo: il fork duplica la conversazione, non i file. Le modifiche al codice fatte in un ramo sono reali e condivise da qualsiasi sessione che lavora nella stessa cartella: per i file, il punto di ripristino resta Git.

🤖 exec resume: riprendere anche i run non interattivi

La parte che uso di più negli script è codex exec resume: la modalità non interattiva ha la sua ripresa dedicata, con la stessa logica della TUI. codex exec resume --last riaggancia il run più recente della cartella corrente, codex exec resume <session-id> uno specifico, e in entrambi i casi posso passare subito il prompt di follow-up.

È il tassello che rende codex exec incrementale: il primo run costruisce il contesto — capisce il repo, fa il grosso del lavoro — e i successivi lo riusano invece di ripartire da zero. In una pipeline, ogni step riprende il contesto dello step precedente passando la stessa sessione.

Con --json ottengo eventi JSONL riga per riga, comodi da processare negli script; --all allarga la ricerca del run più recente a tutte le directory. Sono gli stessi mattoni che uso per le automazioni notturne: un run lungo la sera, follow-up mirati la mattina.

# primo run: costruisce il contesto
codex exec "analizza il repo e proponi un piano di refactor"

# follow-up sullo stesso contesto, senza ripartire
codex exec resume --last "applica il punto 1 del piano"

# ripresa puntuale per session ID, con output JSONL
codex exec resume <session-id> --json "aggiorna i test"

⚠️ I limiti da conoscere: transcript, non stato del modello

La ripresa ricostruisce il contesto rileggendo il transcript, non ripristinando lo stato interno del modello. Per le sessioni lunghe significa due cose: la riapertura richiede qualche istante, e un transcript molto lungo può avvicinarsi ai limiti di contesto prima che la storia sia tutta ricaricata. Dopo un resume su un task interrotto a metà, due righe mie — «eravamo a X, lo stato attuale è Y» — riorientano il modello più in fretta che lasciarlo dedurre tutto dal log.

Attenzione anche ai comandi che sembrano innocui: /clear non pulisce lo schermo, inizia una conversazione nuova; per pulire la vista tenendo il contesto si usa Ctrl+L. Confonderli significa ritrovarsi con una sessione vergine senza volerlo — recuperabile col picker, ma è un giro in più.

Infine, la persistenza copre la conversazione, non le regole del progetto. Le convenzioni, le decisioni architetturali e i vincoli che ogni sessione deve conoscere stanno meglio in AGENTS.md, che Codex legge a ogni avvio: la sessione è per «continua quello che stavo facendo», il file di progetto è per «capisci questo progetto».

✅ Il flusso che seguo per non perdere il lavoro

Messi insieme, questi comandi diventano un'abitudine sola: non chiudo mai un lavoro sperando di ricordarmelo, lo lascio in una sessione che so ritrovare. Il mini-flusso che seguo, in ordine:

• Riprendo con *--last* per il lavoro quotidiano su un solo filo, e passo al picker solo quando i fili sono più di uno.
• Biforco prima di osare: un codex fork non costa nulla e mi salva la strada buona se l'esperimento non regge.
• Uso /side per le divagazioni: le domande di controllo non devono sporcare il contesto del task principale.
• Negli script incateno i run con codex exec resume --last, così ogni step riusa il contesto dello step precedente.
• Archivio ed elimino con codex archive e codex delete: un picker corto è un picker utile.