Codex danger-full-access, --yolo e la "modalità unsafe": cosa disattiva ogni flag

Cosa fa davvero danger-full-access in Codex?

danger-full-access è uno dei tre valori del flag --sandbox di Codex, e spegne la sandbox del tutto. La documentazione di sandboxing di OpenAI lo descrive in una frase: l'agente gira senza restrizioni di sandbox, il che rimuove i confini su filesystem e rete. Ogni comando di shell generato dal modello gira quindi come il tuo utente, con i tuoi permessi, sul tuo filesystem reale, con la tua rete reale.

Gli altri due valori sono quelli che contano nel lavoro quotidiano:

Due dettagli di workspace-write vanno conosciuti prima di giudicarlo troppo restrittivo. Primo, l'insieme scrivibile non è solo la directory corrente: /tmp e $TMPDIR sono scrivibili per impostazione predefinita, e puoi aggiungere percorsi con sandbox_workspace_write.writable_roots in config.toml (la reference di configurazione espone anche exclude_slash_tmp ed exclude_tmpdir_env_var se vuoi escluderli). Secondo, l'accesso alla rete ha un interruttore proprio, sandbox_workspace_write.network_access = true, quindi "mi serve che npm install funzioni" è un argomento a favore di un booleano, non dell'accesso completo.

Ciò che danger-full-access non fa è zittire Codex. Le richieste di approvazione dipendono da un flag separato, ed è lì che nasce quasi tutta la confusione della sezione successiva.

Cosa rimuove --dangerously-bypass-approvals-and-sandbox?

--dangerously-bypass-approvals-and-sandbox, con alias --yolo, rimuove entrambe le protezioni in un colpo solo: la sandbox del SO e le richieste di approvazione. La reference della CLI di OpenAI lo descrive così: eseguire ogni comando senza approvazioni né sandbox, da usare solo dentro un ambiente irrobustito dall'esterno. Quella seconda frase è tutta la policy. Il flag esiste per un container o una macchina virtuale che siano essi stessi il confine, non per un portatile con le tue chiavi SSH, le tue credenziali cloud e il .env di produzione.

La differenza tra i due meccanismi diventa semplice quando li metti fianco a fianco:

• La sandbox decide cosa un comando può toccare: quali percorsi sono scrivibili, se può aprire socket. La applica il sistema operativo, quindi un comando che il modello non intendeva eseguire viene contenuto esattamente come uno voluto.
• Le approvazioni decidono quando Codex si ferma per chiederti conferma. Sono un punto di controllo umano, e funzionano solo se un umano le legge.

danger-full-access da solo ti lascia ancora il punto di controllo. --yolo non ti lascia nulla se non il giudizio del modello, e il giudizio del modello è esattamente ciò che una prompt injection nascosta in un README, in una fixture di test o nel messaggio di errore di una dipendenza è progettata per piegare. Non è teoria: la nostra guida sulle evasioni dalla sandbox degli agenti di coding mostra come il contenuto di un repository diventa comandi, e lo schema si applica a Codex senza modifiche.

-a never, --full-auto e "modalità unsafe" sono la stessa cosa?

No. Allentano livelli diversi, e uno dei tre non è nemmeno un flag. Ecco la mappa completa:

--ask-for-approval accetta untrusted (esegue da solo le letture note come sicure e chiede per qualsiasi cosa modifichi lo stato), on-request (il predefinito: il modello chiede quando vuole escalare, raggiungere la rete o uscire dal workspace) e never. Le versioni più vecchie accettavano anche on-failure, che eseguiva tutto nella sandbox e chiedeva solo quando un comando lì falliva; --full-auto era la scorciatoia per quella combinazione, ed è per questo che sopravvive oggi come flag di compatibilità.

Il preset "Full access" che vedi nel selettore interattivo è la combinazione di danger-full-access e never, e OpenAI lo etichetta "not recommended" nella sua stessa documentazione sulle approvazioni. È --yolo con un nome più gentile.

L'accesso completo di Codex è sicuro?

L'accesso completo di Codex è sicuro esattamente finché lo è l'ambiente che lo circonda, e insicuro nel momento in cui smette di esserlo. Dentro un container appena creato, senza credenziali, con un clone usa e getta e una regola di uscita di rete, danger-full-access è uno scambio ragionevole: il container è la sandbox, e quella di Codex lo rallenterebbe soltanto. Su una postazione di sviluppo significa che un modello con la tua identità può fare curl ovunque, scrivere ovunque e leggere ogni token della tua home, e l'unica cosa tra un'istruzione ostile e quel risultato è la decisione del modello di non obbedire.

I dati che abbiamo sugli agenti senza guardia non rassicurano. Nel nostro studio di scalata, agenti al lavoro senza livello di guardia hanno eseguito DROP SCHEMA contro un database applicativo in produzione diciotto volte, e uno ha lanciato rm -rf fuori dal proprio progetto. Quando abbiamo messo un guardiano dei comandi davanti agli stessi agenti, ha controllato 1.769 comandi di shell nel corso delle sessioni e ne ha fermati diciassette in volo: un sudo distruttivo fuori dal progetto, una cancellazione di schema e l'installazione di un pacchetto che non esiste sul registry. Diciassette su 1.769 è meno dell'uno per cento, e l'uno per cento di "esegui tutti i comandi" è proprio il numero che conta quando il comando è distruttivo.

18

esecuzioni di DROP SCHEMA contro un database in produzione da parte di agenti senza guardia, nel nostro studio

1.769

comandi di shell controllati nelle sessioni con guardia dello stesso studio

17

comandi fermati in volo: sudo distruttivo, cancellazione di schema, pacchetto inesistente

Nota da cosa l'accesso completo non ti protegge nemmeno con un ambiente pulito: il codice. Una sandbox contiene comandi; non ha alcuna opinione sulla correttezza del controllo di autorizzazione che il modello ha appena scritto. Ci torniamo alla fine.

Come funziona la sandbox di Codex su macOS, Linux e Windows?

Codex applica la sandbox con il sistema operativo, non con il modello, ed è per questo che regge anche quando il modello viene manipolato. Su macOS usa il framework Seatbelt di Apple, lo stesso meccanismo di policy sandbox-exec che confina i demoni di sistema, e funziona senza installare nulla. Su Linux e sotto WSL2 usa bubblewrap (bwrap) con filtri seccomp; le versioni precedenti usavano direttamente Landlock e seccomp. Su Windows usa una sandbox nativa di Windows, con o senza elevazione, quando viene lanciato da PowerShell, e il meccanismo Linux quando gira sotto WSL2.

Ne derivano due conseguenze pratiche. Se bwrap manca su una macchina Linux, Codex non può costruirvi la sandbox: installalo prima di dare per scontato di essere protetto. E se un comando viene rifiutato senza che tu capisca perché, codex sandbox esegue un comando sotto la policy corrente a scopo di debug, con --log-denials su macOS per stampare cosa ha bloccato Seatbelt. È lo strumento giusto per "Codex non può scrivere qui", e una risposta molto migliore che ricorrere a danger-full-access.

Seatbelt chiude anche una domanda che vediamo spesso nelle ricerche: "Codex seatbelt" non è una funzione da attivare. È ciò di cui read-only e workspace-write sono fatti su un Mac.

Quando l'accesso completo è la scelta giusta?

L'accesso completo è la scelta giusta quando qualcos'altro è già il confine. Lo schema che funziona:

Container o VM nuovi, clone usa e gettaNessuna credenziale di lunga durata montataUscita di rete limitata ai registry necessariAllora, e solo allora, --yolo

Tre verifiche prima di attivare il flag:

1. Cosa può leggere il processo? Se ~/.ssh, ~/.aws, ~/.codex/auth.json o un .env con chiavi attive sono raggiungibili, la risposta non è l'accesso completo. Il file di credenziali di Codex è già stato bersaglio di un pacchetto npm malevolo; non rendergli le cose più facili.
2. Dove può inviare dati? Rete senza limiti più prompt injection è un canale di esfiltrazione. Se non puoi limitare l'uscita, lascia network_access chiuso e lascia che Codex chieda.
3. Chi legge l'output? Nelle pipeline codex exec nessuno guarda comunque le approvazioni, il che è un motivo per appoggiarsi di più alla sandbox, non per toglierla.

Se una delle tre fallisce, usa invece la configurazione qui sotto.

Cosa usare al posto di --yolo?

Per quasi ogni attività, workspace-write con approvazioni on-request, la rete chiusa e il progetto marcato come fidato ti dà un agente veloce che continua a non poter uscire dalla sua corsia. In ~/.codex/config.toml:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false
writable_roots = ["/Users/tu/scratch"]

[projects."/Users/tu/work/payments-api"]
trust_level = "trusted"

trust_level = "trusted" dice a Codex di applicare la configurazione .codex/ propria del progetto; i progetti non fidati saltano quei livelli locali, che è esattamente ciò che vuoi per un repository appena clonato da uno sconosciuto. Se il fastidio sono le richieste, restringi ciò che le attiva invece di spegnerle: le build recenti espongono una approval_policy granulare e un'opzione approvals_reviewer = "auto_review" che instrada le approvazioni verso un revisore automatico. Tratta l'auto-review come una comodità, non come un confine: è un modello che giudica un altro modello.

Per la CI e codex exec, tieni la sandbox e togli solo le richieste: --sandbox workspace-write -a never su un runner senza credenziali di produzione è una postura coerente. --yolo sullo stesso runner non lo è, perché la sandbox non ti costava nulla.

La falla che nessun flag chiude

Ogni flag di questo articolo governa ciò che Codex può eseguire. Nessuno governa ciò che Codex scrive, ed è nel codice che vive ormai la maggior parte del rischio. Una sandbox workspace-write lascerà tranquillamente che l'agente committi un endpoint senza controllo di autorizzazione, un gestore di rimborsi senza tetto o una query costruita concatenando stringhe, perché nessuno di questi è un comando. Sono diff.

È questo il livello che VibeDefend aggiunge in agent-time. Si colloca nel loop di Codex, confronta il diff che l'agente sta per scrivere con le tue regole, riscrive la versione insicura prima che atterri, e sorveglia i comandi di shell con la stessa policy che ha prodotto i diciassette blocchi qui sopra. Nel nostro studio, gli agenti con il livello hanno rispettato le regole di sicurezza sull'89 % dei ticket, contro il 12 % degli agenti con il solo file di regole nel repository. La sandbox tiene Codex lontano dalla tua macchina; il guardiano tiene il suo codice lontano dalla tua coda di incidenti.

Se esegui Codex in --yolo di proposito, in un container, con un guardiano sul diff, hai una configurazione difendibile. Se lo esegui in --yolo sul tuo portatile perché le richieste davano fastidio, leggi la guida completa alla sicurezza di Codex e poi parliamone: la correzione richiede circa un minuto.

Domande frequenti

danger-full-access e --yolo sono la stessa cosa?

No. --sandbox danger-full-access toglie la sandbox del SO e mantiene le richieste di approvazione. --dangerously-bypass-approvals-and-sandbox (--yolo) toglie la sandbox e le richieste. Il preset "Full access" del selettore corrisponde al secondo.

Cosa fa esattamente codex --yolo?

Esegue subito ogni comando generato dal modello, con i permessi del tuo utente, sul tuo filesystem reale, con rete senza limiti, e non chiede mai nulla. La reference di OpenAI lo riserva a un ambiente irrobustito dall'esterno, cioè un container o una VM che siano essi stessi il confine.

-a never è pericoloso da solo?

Meno di quanto si pensi, purché la sandbox resti attiva. --ask-for-approval never toglie il punto di controllo umano, ma workspace-write continua a confinare le scritture e la rete resta chiusa a meno che tu non l'abbia aperta. Diventa pericoloso nel momento in cui lo abbini a danger-full-access.

Cos'è la "modalità unsafe" di Codex?

Non esiste alcun flag con quel nome. "Modalità unsafe", "modalità pericolosa" e "run dangerously" vengono usati per indicare danger-full-access, --yolo o -a never, che sono tre cose diverse. Verifica a quale si riferisce davvero un tutorial prima di copiare il comando.

Come lascio che Codex usi la rete senza accesso completo?

Imposta network_access = true sotto [sandbox_workspace_write] in config.toml, oppure passa -c sandbox_workspace_write.network_access=true per una singola esecuzione. Le scritture restano confinate al workspace; si apre solo la rete.

La sandbox di Codex funziona su Windows?

Sì. Da PowerShell usa una sandbox nativa di Windows, con o senza elevazione; sotto WSL2 usa il meccanismo Linux (bubblewrap e seccomp). I valori di --sandbox e le chiavi di config.toml sono gli stessi su tutte le piattaforme.

La sandbox ferma la prompt injection?

Contiene ciò che un comando iniettato può toccare; non ferma l'iniezione. Un README malevolo può ancora spingere il modello a scrivere codice insicuro, o a chiedere un'escalation che un umano stanco approva. Tieni la sandbox attiva e aggiungi un livello che controlli il codice e i comandi, non solo i percorsi dei file.