Codex continua a chiedere l'approvazione? Criteri di approvazione, sandbox e “don't ask again” spiegati
Codex chiede l'approvazione quando un comando deve uscire dalla sua sandbox. La maggior parte delle lamentele del tipo “continua a chiedere” nasce da una sandbox troppo restrittiva, da un'impostazione che non esiste più o da un “don't ask again” che è durato solo per la sessione.
RISPOSTA BREVE
Nella versione attuale di Codex, approval_policy può essere on-request (il valore predefinito: il modello chiede quando ne ha bisogno), never o una tabella granular; untrusted è stato rimosso e on-failure ora è solo un altro nome per on-request. A decidere quanto spesso ti viene chiesto è soprattutto la sandbox: con sandbox_mode = "workspace-write" Codex modifica i file ed esegue i comandi all'interno del progetto senza chiedere. Per i comandi di cui ti fidi sempre, aggiungi una prefix_rule con decision = "allow" in ~/.codex/rules/default.rules. È anche lì che si salva “don't ask again for commands that start with …”.
Prima di tutto: cosa è cambiato in Codex
Molte guide e risposte nei forum descrivono impostazioni che non funzionano più. Prima di regolare qualsiasi cosa, confronta il tuo ~/.codex/config.toml con questo elenco:
| Vecchia impostazione | Oggi |
|---|---|
approval_policy = "untrusted" | Rimossa. Codex segnala “approval_policy = "untrusted" is no longer supported; remove this setting” (non è più supportata; rimuovi questa impostazione). La documentazione suggerisce invece sandbox_mode = "read-only" con on-request. |
approval_policy = "on-failure" | Ancora accettata, ma solo come alias di on-request. |
--full-auto | Non compare più nel riferimento della CLI. Il flag più vicino è --approve-for-me (alias --not-so-yolo): revisione automatica delle approvazioni con on-request e la sandbox workspace-write. |
[profiles.name] dentro config.toml | Da Codex 0.134.0, --profile name legge invece $CODEX_HOME/name.config.toml. Una chiave profile = "x" rimasta nel file ora genera un errore. |
/approvals | Usa /permissions (“Set what Codex can do without asking first.”) |
Anche la documentazione di Codex si è spostata: le vecchie pagine developers.openai.com/codex ora reindirizzano a learn.chatgpt.com.
Come Codex decide di chiedere
Due impostazioni lavorano insieme. La sandbox limita ciò che un comando può toccare: i file fuori dal progetto, la rete. Il criterio di approvazione decide cosa succede quando un comando ha bisogno di più di quanto la sandbox consente.
| sandbox_mode | Cosa può fare Codex senza chiedere |
|---|---|
read-only (predefinito) | Leggere file ed eseguire comandi in una sandbox di sola lettura |
workspace-write | Leggere, modificare ed eseguire comandi nella directory di lavoro automaticamente |
danger-full-access | Tutto, senza sandbox. Sconsigliato |
| approval_policy | Comportamento |
|---|---|
on-request (predefinito) | Il modello decide quando chiedere. I comandi consentiti dalla sandbox vengono eseguiti senza approvazione |
never | Non chiede mai. Tutto ciò che fallisce viene restituito al modello, senza essere inoltrato a te |
{ granular = { … } } | Mantiene interattive alcune categorie di richieste e rifiuta automaticamente le altre (sandbox_approval, rules, skill_approval, request_permissions, mcp_elicitations) |
Quindi, se sei in read-only, ogni modifica richiede un sì. È la causa più comune in assoluto di “Codex chiede per tutto”. Anche in workspace-write, .git, .codex, .agents e .aws restano in sola lettura, e l'accesso alla rete è disattivato finché non lo attivi.
Questa è la configurazione di esempio della documentazione di OpenAI, con le opzioni del workspace spiegate:
Le versioni più recenti offrono anche i profili di autorizzazione (default_permissions con i profili integrati :read-only, :workspace e :danger-full-access). Usa i profili oppure sandbox_mode, non entrambi.
I preset nella CLI, nell'estensione IDE e nell'app
Non devi per forza modificare il TOML. Nella CLI, /permissions apre i preset; nell'app e nell'estensione IDE c'è un controllo delle autorizzazioni sotto la casella di composizione. I preset della CLI sono:
- Read Only: legge il workspace; serve un'approvazione per modificare file o accedere a Internet.
- Default: modifica i file nel workspace; serve un'approvazione per accedere a Internet o modificare altri file.
- Full Access: modifica file fuori dal workspace e usa Internet senza chiedere.
L'app e l'estensione IDE descrivono la stessa scelta come Ask for approval, Approve for me e Full access. Nelle schermate più vecchie dell'IDE si chiamano Chat, Agent e Agent (Full Access).
Consentire comandi specifici con le regole
Quando vuoi che Codex esegua un comando fuori dalla sandbox senza chiedere (ad esempio gh pr view), scrivi una regola. Le regole sono sperimentali e si trovano in un file .rules dentro una cartella rules/ accanto a un livello di configurazione, ad esempio ~/.codex/rules/default.rules:
allow: esegue fuori dalla sandbox senza chiedere.prompt: chiede prima di ogni comando corrispondente.forbidden: blocca senza chiedere.
Quando corrispondono più regole, vince la più restrittiva: forbidden prevale su prompt, che prevale su allow. Prova un comando con codex execpolicy check prima di affidarti a una regola.
Cosa salva davvero “don't ask again”
La richiesta di approvazione della CLI di Codex offre diversi tipi di “sì”, con durate molto diverse:
| Opzione | Quanto dura |
|---|---|
| Yes, proceed | Solo questo comando |
Yes, and don't ask again for commands that start with <prefix> | In modo permanente (scritta come regola in ~/.codex/rules/default.rules) |
| Yes, and don't ask again for this command in this session | Fino alla fine della sessione |
| Yes, and don't ask again for these files | Modifiche ai file, per questa sessione |
Se continui a scegliere l'opzione di sessione, domani ti verrà chiesto di nuovo. Scegli l'opzione con prefisso, oppure scrivi tu la regola.
Codex su Windows
Windows era la piattaforma in cui il problema “chiede per tutto” era più grave. Nella issue #10187 un membro del team di OpenAI ha spiegato il motivo: “Without a sandboxing mechanism, all tool calls need to be manually approved on Windows.” (senza un meccanismo di sandbox, su Windows tutte le chiamate agli strumenti vanno approvate manualmente). Ora Codex ha una sandbox nativa per Windows e la usa per impostazione predefinita:
mxc: la sandbox consigliata sui dispositivi Windows compatibili.elevated: il fallback preferito quando MXC non è disponibile.unelevated: un fallback legacy.
Esegui /setup-default-sandbox nella CLI per configurare la sandbox elevated (oppure codex sandbox setup --elevated per il reparto IT). Windows 11 è consigliato; Windows 10 1809 o versioni successive sono supportati per quanto possibile. Se lavori in WSL, lì Codex usa la sua sandbox Linux, e WSL1 non è più supportato.
La configurazione di progetto viene caricata solo nei progetti attendibili
Un .codex/config.toml all'interno di un repository viene letto solo se consideri attendibile il progetto. Se le impostazioni del progetto sembrano ignorate, il motivo è questo. Una voce di attendibilità nella configurazione utente ha questo aspetto:
Le impostazioni sono organizzate a livelli, dal più alto: flag della riga di comando e override -c, il .codex/config.toml del progetto attendibile, il file --profile, il tuo ~/.codex/config.toml, poi i valori predefiniti di sistema.
Su --yolo
--dangerously-bypass-approvals-and-sandbox (alias --yolo) esegue ogni comando senza approvazioni né sandbox. Il codice sorgente lo descrive come “EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed.” (estremamente pericoloso, pensato solo per ambienti isolati dall'esterno). approval_policy = "never" con danger-full-access fa la stessa cosa dal file di configurazione. Se vuoi solo meno richieste, workspace-write più qualche regola allow ti porta lì con la sandbox ancora attiva.
Per le richieste che restano
Quando Codex chiede solo per ciò che conta (la rete, i file fuori dal progetto, un push), il problema che resta è accorgersi della domanda. Pet Island mette le approvazioni di comandi e modifiche ai file di Codex su una piccola isola nella parte alta dello schermo, con il comando o il diff, così puoi consentirle o negarle senza cercare il terminale giusto. Mostra quando Codex sta lavorando e quando ha finito, e le domande di Codex ti portano alla finestra giusta con un clic. Funziona con la CLI di Codex e con l'app Codex, e se l'isola è chiusa Codex chiede nella sua finestra come al solito.
FAQ
Come faccio a impedire a Codex di chiedere continuamente l'approvazione?
Usa sandbox_mode = "workspace-write" così Codex può modificare file ed eseguire comandi all'interno del progetto, mantieni approval_policy = "on-request" e aggiungi voci prefix_rule con decision = "allow" in ~/.codex/rules/default.rules per i comandi di cui ti fidi sempre.
approval_policy = "untrusted" è ancora supportato?
No. La versione attuale di Codex lo rifiuta con “approval_policy = "untrusted" is no longer supported; remove this setting”. Usa invece sandbox_mode = "read-only" con approval_policy = "on-request".
Che fine ha fatto --full-auto?
Non compare più nel riferimento della CLI di Codex. L'opzione più vicina è --approve-for-me (alias --not-so-yolo), che usa la revisione automatica delle approvazioni con on-request e la sandbox workspace-write.
Perché “don't ask again” non viene mantenuto?
“Don't ask again for this command in this session” dura solo per la sessione. Scegli “don't ask again for commands that start with …”, che salva una regola in ~/.codex/rules/default.rules.
Perché Codex chiede di più su Windows?
Senza sandbox, ogni chiamata a uno strumento richiede un'approvazione. Ora Codex usa per impostazione predefinita una sandbox nativa per Windows; esegui /setup-default-sandbox se non è configurata.
Perché il .codex/config.toml del mio progetto viene ignorato?
Codex carica la configurazione di progetto solo per i progetti attendibili.
Fonti
Ogni impostazione e comportamento descritti in questa pagina sono stati verificati su queste pagine il 26 ottobre 2026. Gli agenti cambiano in fretta: se qualcosa non corrisponde più, fa fede la pagina ufficiale.
- OpenAI: Codex agent approvals and security
- OpenAI: Codex permission modes
- OpenAI: Codex config basics
- OpenAI: Codex sample config
- OpenAI: Codex rules
- OpenAI: Codex Windows sandbox
- OpenAI: Codex CLI reference
- OpenAI: Codex slash commands
- Codice sorgente di openai/codex (richiesta di approvazione, errori di configurazione)
- Issue #10187: Codex chiede ripetutamente l'approvazione dei comandi
- Issue #5131: bisogna sempre approvare le modifiche ai file
- Issue #29406: la richiesta di approvazione persiste nonostante “don't ask again”