Vuoi che Codex lavori e basta: modifica i file, esegue i comandi e prosegue senza chiederti conferma a ogni passaggio. Attivi "Full Access", eppure *continua* a fermarsi. Ecco perché succede e come renderlo davvero autonomo, con test eseguiti su Codex CLI v0.145.0.
Il motivo: "Auto mode" non è un singolo interruttore. Codex gestisce separatamente il sandbox, cioè cosa può toccare, e la policy di approvazione, cioè quando deve fermarsi a chiedere; l'accesso alla rete è un terzo controllo indipendente. Allentare un vincolo non modifica gli altri, e un aggiornamento di Codex può riportare silenziosamente la sessione alla policy predefinita.
CLI senza interventi: --yolo è l'unico flag che rimuove tutti i controlli insieme. Se preferisci mantenere il sandbox, imposta esplicitamente entrambi gli assi per una configurazione più prudente. Fallo all'avvio della sessione e verifica di nuovo dopo ogni aggiornamento.
# Davvero senza interventi — nessun sandbox, nessuna richiesta (solo ambiente usa e getta):
codex --yolo
# Più prudente — modifica liberamente il progetto, ma chiede conferma per uscirne:
codex --sandbox workspace-write --ask-for-approval on-requestNell'app senza interventi: apri il menu delle approvazioni, scegli Full access e selezionalo di nuovo dopo ogni aggiornamento: gli upgrade reimpostano la modalità.
Questa è la risposta breve. Il resto della guida mette ordine tra tutte le modalità, spiega a cosa corrispondono internamente e aiuta a scegliere quella adatta.
Le modalità di Codex a confronto
Il sandbox stabilisce cosa l'agente può toccare, inclusi file e rete; la policy di approvazione determina quando deve chiedere il tuo consenso. Le modalità automatiche sono semplicemente combinazioni di queste due impostazioni, con nomi diversi tra app desktop e CLI.
| Nome nell'app | Cosa fa | Equivalente CLI |
|---|---|---|
| Ask for approval | Modifica i file nel workspace, esegue i normali comandi locali e chiede conferma prima di accedere a internet o fare qualunque cosa fuori dal workspace | sandbox_mode = "workspace-write" + approval_policy = "on-request" |
| Approve for me (impostazione predefinita attuale dell'app) | Stessi confini, ma le richieste di approvazione idonee vengono affidate a un revisore AI anziché a te (è Auto-review) | quanto sopra + approvals_reviewer = "auto_review" |
| Full access | Nessun sandbox, nessuna richiesta di approvazione, accesso senza restrizioni a file e rete | sandbox_mode = "danger-full-access" + approval_policy = "never" |
Se lavori soprattutto dalla CLI, puoi impostare direttamente questi valori con --sandbox e --ask-for-approval, oppure cambiare preset durante la sessione dal selettore /permissions. Se invece devi ancora scegliere il client, è un tema distinto: qui abbiamo confrontato Codex e Claude Code. Questo articolo riguarda le impostazioni.
Perché "Full Access" continua a chiedere conferma
Le ragioni sono tre e possono sommarsi.
Sandbox e approvazioni sono controlli distinti. La coppia workspace-write + on-request permette a Codex di modificare liberamente il progetto, ma lo ferma ai suoi confini: una chiamata di rete, un file esterno al repository, un sudo. Se allarghi il sandbox ma lasci le approvazioni su richiesta, continuerai a ricevere prompt a ogni confine.
La rete ha un controllo dedicato. Anche Full Access può gestire internet separatamente dal filesystem. Come ha osservato @mxcl (16 luglio 2026), Codex "cannot use the Internet without full access, ending task until the user enables full access." La scrittura sui file e l'accesso alla rete non sono lo stesso permesso.
Gli aggiornamenti reimpostano la modalità. Diversi utenti hanno riscontrato il problema a fine luglio 2026: l'aggiornamento di Codex riporta silenziosamente le sessioni attive alla policy predefinita. @s_rafcon (22 luglio): i thread "switch their Full access flag to the default flag and [are] stuck asking for approval on every single edit." Imposta la modalità all'*inizio* di una sessione e ricontrollala dopo ogni update.
CLI: --full-auto non c'è più, usa questo al suo posto
codex --full-auto era la scorciatoia per "lavora nel mio progetto senza chiedere" (approval_policy = "on-request" + sandbox_mode = "workspace-write"). Il comando interattivo non lo accetta più. Test su v0.145.0:
$ codex --full-auto
error: unexpected argument '--full-auto' foundImposta invece esplicitamente i due assi: è esattamente ciò che faceva il vecchio flag.
# Sostituto attuale di --full-auto
codex --sandbox workspace-write --ask-for-approval on-request
# Oppure, in modalità non interattiva, senza prompt ma mantenendo il sandbox:
codex -a never -s workspace-write exec "your task"codex exec --full-auto accetta ancora il flag negli script; l'errore riguarda solo il comando interattivo. In base a codex --help, --ask-for-approval accetta untrusted / on-request / never, mentre --sandbox accetta read-only / workspace-write / danger-full-access. Ogni "modalità" dell'app è una combinazione di questi due parametri.
--yolo: quando ha senso bypassare tutto
--yolo è l'alias breve di --dangerously-bypass-approvals-and-sandbox. È il vero interruttore "hands-off": combina danger-full-access e never, senza limiti sul filesystem né richieste di approvazione. È rimasto anche dopo la rimozione di --full-auto proprio perché il nome rende evidente il rischio: su v0.145.0 codex --yolo viene interpretato correttamente, mentre codex --full-auto genera un errore.
Molti utenti esperti lo usano come impostazione predefinita e, nel contesto giusto, hanno ragione: usalo quando è l'ambiente stesso a fare da protezione. Considera la macchina come sacrificabile:
- Eseguilo in una VM o in un dev container usa e getta, non sul computer di lavoro quotidiano.
- Rimuovi prima dall'ambiente le credenziali di produzione.
- Mantieni il compito circoscritto, poi controlla
git diffprima di proseguire.
Dato che --yolo elimina ogni barriera, un comando accidentale come rm -rf, git push o DROP TABLE viene eseguito senza prompt: è il prezzo della velocità. (Usare Codex con un endpoint self-hosted o compatibile con Anthropic tramite un provider di modelli personalizzato non cambia nulla: il sandbox non dipende dal modello dietro l'API.)
"Approve for me" / Auto-review: far approvare le azioni a un'AI
La modalità più recente, nonché predefinita nell'app, è Auto-review. Le escalation idonee vengono passate a un agente revisore separato, un piccolo Codex basato su GPT-5.4 Thinking (low), che approva o rifiuta fornendo una motivazione. OpenAI la definisce "a reviewer swap, not a permission grant": non amplia le directory scrivibili e non abilita la rete, cambia solo *chi dice sì*.
I dati arrivano dalla valutazione pubblicata da OpenAI il 30 aprile 2026: con Auto-review l'intervento umano è necessario circa 200x meno spesso rispetto all'approvazione manuale, e viene approvato circa il 99,1% delle escalation esaminate (99,93% considerando tutte le azioni). Nella loro istantanea illustrativa di 10.000 azioni, 9.280 sono state eseguite nel sandbox senza modifiche, 720 sono passate al revisore e solo 7 sono state rifiutate.
Esistono protezioni contro una sequenza incontrollata di rifiuti: il turno si interrompe dopo 3 rifiuti consecutivi, oppure dopo 10 rifiuti in una finestra mobile delle ultime 50 revisioni. Quando si ferma, esegui /approve per aprire il selettore Auto-review Denials e autorizzare una singola azione per un nuovo tentativo.
Il rovescio della medaglia è che questi controlli di sicurezza possono bloccare le esecuzioni lunghe. A fine luglio 2026, utenti impegnati in attività /goal di molte ore hanno segnalato che il periodico prompt "keep waiting?" interrompeva flussi di lavoro che in precedenza giravano senza supervisione per giorni. OpenAI afferma inoltre chiaramente che "should not be treated as a guarantee of security": il recall dei red team è elevato ma imperfetto (90,3% overreach, 99,3% prompt injection, 96,1% misaligned-model). È una buona impostazione predefinita, ma non sostituisce un sandbox per il lavoro ad alta criticità.
Per attivarla tramite configurazione anziché dall'interfaccia:
approvals_reviewer = "auto_review"
[auto_review]
policy = """
Describe what the reviewer should allow or block here.
"""Quale modalità conviene usare davvero?
- Sviluppo locale di tutti i giorni:
workspace-write+on-request("Ask for approval"). Mantieni il veto su tutto ciò che esce dal repository, dove si concentrano i danni più seri. - Esecuzioni lunghe senza supervisione: "Approve for me" (Auto-review). Tieni presente che si ferma comunque sulle azioni che segnala, quindi non è un'esperienza a zero interventi.
- Lavori una tantum e poco puliti in un ambiente usa e getta:
--yolo. È la soluzione più rapida e più pericolosa, sicura solo se l'ambiente non può subire danni rilevanti. - Lettura o revisione di una codebase:
read-only. Nessuna scrittura, nessuna sorpresa.
La sintesi onesta è questa: non esiste un'impostazione insieme completamente autonoma e completamente sicura. Ogni passo verso il funzionamento hands-off sostituisce il tuo giudizio con quello di un classificatore. È uno scambio sensato per le attività di routine, e una cattiva idea sull'infrastruttura di produzione. Scegli in base al compito, non una volta per tutte.
FAQ
Codex ha una modalità automatica?
Sì, ma è un insieme di preset anziché un unico interruttore. Nell'app, "Ask for approval", "Approve for me" e "Full access" sono le modalità automatiche; nella CLI puoi ottenere lo stesso comportamento combinando --sandbox e --ask-for-approval, oppure usando /permissions.
Come faccio a far approvare automaticamente tutti i comandi a Codex?
Imposta approval_policy = "never". In abbinamento a workspace-write smette di mostrare prompt all'interno del sandbox; con danger-full-access, cioè --yolo, smette completamente di chiedere conferma. Quest'ultima opzione elimina tutte le protezioni, quindi usala soltanto in un ambiente isolato.
Cos'è la modalità Auto-review di Codex?
Auto-review (approvals_reviewer = "auto_review", mostrata come "Approve for me") inoltra le decisioni di approvazione a un agente revisore AI anziché a te. Approva circa il 99% delle azioni che esamina e richiede un umano circa 200x meno spesso, ma non è una garanzia di sicurezza.
--full-auto funziona ancora?
Non nella CLI interattiva. Testato su v0.145.0, codex --full-auto restituisce "unexpected argument." codex exec --full-auto continua ad accettarlo come alias deprecato per gli script. Per l'uso interattivo, imposta invece --sandbox workspace-write --ask-for-approval on-request.
La modalità --yolo è sicura?
No: è proprio questo il senso del nome. Disabilita contemporaneamente il sandbox e tutte le approvazioni. È ragionevole solo in una VM o un container sacrificabile, dopo aver rimosso le credenziali di produzione e limitato con precisione il compito.