Codex CLI --full-auto: cosa fa davvero, perché è deprecato e cosa uso al suo posto
Quando ho iniziato a usare Codex CLI per automazioni vere — script, pipeline, task lunghi — il flag --full-auto era la risposta standard alla domanda "come lo faccio girare senza che mi chieda conferma a ogni comando?". Funziona ancora, ma nel tempo ho capito due cose che le guide veloci non dicono: primo, non è un semplice "salta le approvazioni", perché forza anche la sandbox a workspace-write ignorando qualsiasi --sandbox passato insieme; secondo, su codex exec OpenAI lo mantiene solo come percorso di compatibilità deprecato, con tanto di warning a video. In questo articolo smonto il flag pezzo per pezzo — approvazioni da una parte, sandbox dall'altra — e mostro la combinazione esplicita che uso oggi al suo posto.
🔍 Cosa fa davvero --full-auto: due manopole in un flag solo
Codex CLI ha due controlli indipendenti: la policy di approvazione (quando l'agente si ferma a chiedermi il permesso) e la sandbox (cosa possono toccare i comandi che genera). --full-auto è una scorciatoia che li imposta entrambi: approvazioni disattivate e sandbox in modalità workspace-write, cioè scritture permesse solo dentro il repository corrente e nelle cartelle temporanee.
Il dettaglio che sorprende è la precedenza: se scrivo codex exec --full-auto --sandbox read-only, la parte read-only viene semplicemente ignorata. Il flag forza workspace-write, punto. È un comportamento documentato ma controintuitivo: mi aspetterei che il flag più specifico vinca, invece vince la scorciatoia.
Per questo oggi ragiono sempre in termini di manopole separate: -a (o --ask-for-approval) per le approvazioni, -s (o --sandbox) per il perimetro. Due flag espliciti dicono esattamente quello che fanno; una scorciatoia che ne sovrascrive un'altra è il tipo di sorpresa che preferisco evitare negli script.
# scorciatoia storica (deprecata su codex exec)
codex exec --full-auto "aggiorna le dipendenze e lancia i test"
# equivalente esplicito: approvazioni + sandbox dichiarate
codex exec -a never -s workspace-write \
"aggiorna le dipendenze e lancia i test"Doc ufficiale: approvals e sandbox in Codex ↗
🧱 La sandbox sotto il cofano: tre modi, un perimetro per ogni rischio
La sandbox di Codex ha tre modalità. read-only: i comandi generati dal modello leggono i file ma non scrivono da nessuna parte, nemmeno in /tmp. workspace-write: scritture consentite nel repository e nelle directory temporanee, bloccate ovunque altro. danger-full-access: nessuna restrizione sul filesystem — il nome dice tutto.
Non è una convenzione software ma un confine imposto dal sistema operativo: su macOS Codex usa le policy Seatbelt via sandbox-exec, su Linux costruisce un ruleset Landlock (con bwrap dalle versioni recenti) che limita il processo ai percorsi consentiti. Anche in workspace-write restano protetti alcuni percorsi sensibili del repo, come i metadati di .git.
Capitolo rete: in workspace-write l'accesso di rete dei comandi è spento di default. Se il task ha bisogno di scaricare pacchetti devo abilitarlo io, con sandbox_workspace_write.network_access = true nel config.toml o via -c al volo. È il motivo per cui un npm install dentro Codex a volte fallisce "misteriosamente": non è il registro npm, è la sandbox che fa il suo lavoro.
- 01Il modello propone un comandoCodex valuta la policy di approvazione attiva: never, untrusted, on-request o granulare.
- 02Approvazione o via liberaCon -a never non chiede nulla; con untrusted esegue da solo solo le letture note come sicure.
- 03Il comando entra in sandboxSeatbelt su macOS, Landlock/bwrap su Linux: il perimetro dipende dal modo scelto.
- 04Scritture e rete filtrateworkspace-write: solo repo e cartelle temporanee, rete spenta salvo opt-in esplicito.
Fonte: documentazione ufficiale OpenAI Codex — Agent approvals & security.
⚠️ La deprecazione: perché --full-auto sta sparendo da codex exec
La documentazione ufficiale oggi è esplicita: per le esecuzioni non interattive si usa codex exec --sandbox workspace-write, mentre codex exec --full-auto resta solo come percorso di compatibilità deprecato che stampa un warning. La direzione è chiara: flag espliciti e separati al posto di scorciatoie che impostano più cose insieme.
C'è anche una trappola storica da conoscere. La prima Codex CLI (quella in TypeScript, primavera 2025) aveva un sistema completamente diverso: --approval-mode con i valori suggest, auto-edit e full-auto, e una sandbox basata su Docker. La riscrittura in Rust ha cambiato tutto — policy e sandbox attuali non c'entrano nulla — ma in rete circolano ancora moltissime guide riferite al vecchio schema. Se un tutorial parla di suggest/auto-edit o di sandbox docker, sto leggendo documentazione dell'era precedente.
Il rimpiazzo mentale che uso: --full-auto era "fai tutto tu, ma resta nel repo". La versione moderna della stessa frase è -a never -s workspace-write. Stessa autonomia, stesso perimetro, ma dichiarata per esteso — e senza warning di deprecazione nei log delle pipeline.
Ieri — codex --full-auto
- Un flag solo: approvazioni + sandbox insieme
- Forza workspace-write, ignora --sandbox
- Deprecato su codex exec, warning a video
- Nelle vecchie guide era un approval-mode
Oggi — -a never -s workspace-write
- Due manopole separate e leggibili
- La sandbox la scelgo io, per ogni run
- Forma raccomandata dalla doc ufficiale
- Combinabile: read-only in CI, untrusted in locale
🧪 Le combinazioni che uso davvero, dal laptop alla CI
Separare le due manopole apre combinazioni che con --full-auto non esistevano. Per l'uso interattivo quotidiano il preset Auto (quello di default: workspace-write con approvazioni on-request) è il compromesso giusto: l'agente lavora nel repo e mi chiede il permesso solo per uscire dal perimetro o toccare la rete.
Nei job di sola analisi — report, review, domande sul codice — giro con -s read-only -a never: l'agente legge tutto, non tocca niente, e non si ferma mai ad aspettarmi. È la configurazione che considero il default sano per la CI: se il task non deve scrivere, il perimetro non deve permetterglielo.
All'estremo opposto c'è --dangerously-bypass-approvals-and-sandbox, alias --yolo: niente approvazioni e niente sandbox. Ha un solo caso d'uso legittimo — un container o una VM usa e getta che fa da sandbox esterna — e in quel contesto la stessa doc ufficiale suggerisce danger-full-access per non pagare due strati di isolamento. Sul laptop, con le mie chiavi SSH e i miei file, non parte mai.
Ultima chicca: le combinazioni ricorrenti le salvo come profili nel config.toml e le richiamo con codex --profile nome. E prima di fidarmi di un perimetro lo verifico con codex sandbox macos (o linux): esegue un comando qualsiasi dentro la sandbox scelta e mi mostra cosa viene bloccato.
- Uso quotidiano: preset Auto — workspace-write con approvazioni on-request, nessun flag da ricordare.
- Automazioni nel repo: -a never -s workspace-write, l'erede esplicito di --full-auto, senza warning di deprecazione.
- CI di sola lettura: -s read-only -a never per report e review che non devono scrivere nulla.
- Container usa e getta: danger-full-access solo quando l'isolamento lo garantisce già l'infrastruttura.
- Profili in config.toml: una combinazione per contesto, richiamata con codex --profile nome.
Domande frequenti su codex --full-auto
Il flag --full-auto di Codex CLI funziona ancora?
Sì, ma su codex exec è mantenuto solo come percorso di compatibilità: la documentazione ufficiale lo dichiara deprecato e Codex stampa un warning quando lo uso. La forma raccomandata oggi è esplicita: -a never -s workspace-write, che produce esattamente lo stesso comportamento dichiarando le due impostazioni separatamente.
Perché --sandbox read-only viene ignorato se passo anche --full-auto?
Perché --full-auto non si limita a saltare le approvazioni: forza la sandbox a workspace-write, e questa forzatura ha la precedenza su qualsiasi --sandbox passato accanto. Se voglio davvero un run in sola lettura devo togliere --full-auto e scrivere -s read-only con la policy di approvazione che preferisco.
I comandi in sandbox workspace-write hanno accesso alla rete?
No, di default la rete è spenta: un npm install o un curl falliscono anche se il filesystem è scrivibile. Per abilitarla imposto sandbox_workspace_write.network_access = true nel config.toml, oppure la passo al volo con -c sul singolo comando. È una scelta deliberata: limita l'impatto di prompt injection e dipendenze compromesse.
Che differenza c'è tra danger-full-access e --yolo?
-s danger-full-access toglie le restrizioni sul filesystem ma lascia in piedi il meccanismo delle approvazioni; --dangerously-bypass-approvals-and-sandbox (alias --yolo) disattiva entrambi. Il secondo ha senso solo dentro un container o una VM che fa già da sandbox esterna; sul mio computer resta un flag che non uso mai.
Le guide che parlano di suggest, auto-edit e full-auto sono ancora valide?
No: quella tripletta apparteneva alla prima Codex CLI in TypeScript (2025), insieme alla sandbox basata su Docker. La CLI attuale in Rust usa un modello diverso — --ask-for-approval con never/untrusted/on-request e --sandbox con read-only/workspace-write/danger-full-access. Se un tutorial cita auto-edit o sandbox docker, è riferito alla versione vecchia.
Parliamone
Se questo tema ti riguarda, scrivimi: confrontarsi su codice e AI è sempre tempo speso bene.