Codex CLI approval policy: untrusted, on-request, never e la policy granulare

🔍 Cos'è l'approval policy e perché non è la sandbox

Codex ha due controlli separati e complementari. La sandbox (sandbox_mode: read-only, workspace-write, danger-full-access) è il perimetro tecnico imposto dal sistema operativo: dove i comandi possono scrivere, se possono raggiungere la rete. La approval policy (approval_policy) è il protocollo di interruzione: in quali casi Codex deve fermarsi e chiedermi conferma prima di eseguire — per esempio per uscire dal perimetro, usare la rete o lanciare un comando fuori dall'insieme fidato.

La distinzione conta perché le due manopole falliscono in modi diversi: una sandbox stretta limita i danni anche con poche approvazioni, mentre tante richieste di conferma non rendono sicuro un ambiente senza perimetro. Le configuro sempre insieme, mai una sola delle due.

In sessione le controllo senza toccare file: /status mi mostra policy e sandbox attive, /permissions mi fa cambiare al volo il livello di permessi — è il comando che nelle prime versioni si chiamava /approvals. Da riga di comando la policy si passa con --ask-for-approval (o -a), la sandbox con --sandbox (o -s).

# ~/.codex/config.toml
approval_policy = "on-request"   # untrusted | on-request | never
sandbox_mode    = "workspace-write"

# stessa cosa, per un run singolo
codex --sandbox workspace-write --ask-for-approval on-request

# in sessione: /status per vedere, /permissions per cambiare

🧭 I tre valori: untrusted, on-request, never

untrusted è il più conservativo e il più frainteso: Codex esegue in autonomia solo le operazioni di lettura note come sicure, e chiede conferma per tutto ciò che può mutare stato o innescare esecuzioni esterne — comprese operazioni Git distruttive o flag che sovrascrivono la configurazione. Lo uso sui repository che non conosco, dove voglio vedere ogni mossa.

on-request è lo standard interattivo, quello del preset Auto: l'agente lavora libero dentro la sandbox e mi interpella solo quando vuole andare oltre — modificare file fuori dal workspace, accedere alla rete, lanciare certi comandi. È il compromesso giusto per il lavoro quotidiano su progetti fidati.

never disattiva i prompt di approvazione, ma non è il "liberi tutti" che sembra: la sandbox resta pienamente attiva e Codex fa del suo meglio dentro i vincoli impostati. -a never con -s read-only è una CI di sola lettura che non si ferma mai; con -s workspace-write è l'automazione confinata al repo. Nota per chi arriva da guide vecchie: il valore on-failure è deprecato, non va copiato dai vecchi esempi.

C'è un caso in cui l'approvazione scatta comunque, qualunque policy abbia scelto: le chiamate a tool MCP o app che si dichiarano distruttive. Se il tool annuncia l'annotazione destructive, Codex chiede conferma anche se lo stesso tool si dichiara pure read-only.

⚙️ Policy granulare e Auto-review: le opzioni che le guide saltano

Quando "chiedi tutto" e "non chiedere niente" sono entrambi troppo grossolani, c'è la policy granulare: al posto della stringa, approval_policy accetta un oggetto che governa ogni categoria di richiesta separatamente — escalation di sandbox, prompt delle regole execpolicy, richieste dei server MCP, request_permissions e script delle skill. Posso tenere interattive le escalation di sandbox e rifiutare in automatico gli script delle skill, per dire.

L'altra novità è l'Auto-review: con approvals_reviewer = "auto_review" le richieste di approvazione idonee non arrivano più a me ma a un revisore automatico, che le valuta cercando esfiltrazione di dati, accesso a credenziali e operazioni distruttive — nega le azioni a rischio critico e blocca in attesa quelle ad alto rischio. Si applica solo quando le approvazioni sono interattive (on-request o policy granulare): con never non c'è nulla da revisionare.

Due avvertenze da persona che l'ha provato: il revisore valuta solo le azioni che già richiedono approvazione — quello che resta dentro la sandbox non passa mai da lui — e ogni valutazione è una chiamata al modello in più, quindi incide sui consumi. Lo tratto come difesa in profondità, non come sostituto di una sandbox ben stretta.

✅ Dove vivono le impostazioni e la checklist che seguo

Le impostazioni si stratificano, e conoscere la precedenza evita mezz'ore di debug: vincono i flag CLI e gli override -c, poi i file .codex/config.toml di progetto (dal più vicino), poi il profilo selezionato, poi la configurazione utente in ~/.codex/config.toml, infine i default. Dettaglio di sicurezza che apprezzo: la configurazione di progetto viene ignorata finché il progetto non è fidato, così un repo appena clonato non può caricarsi da solo regole e hook.

Per contesti diversi uso i profili: un profilo prudente con untrusted + read-only per l'esplorazione, uno standard con on-request + workspace-write per il lavoro, uno never per le automazioni. Li richiamo con --profile e quando qualcosa non torna il primo comando è /status, il secondo codex doctor.

• Repo sconosciuto: untrusted + read-only — vedo ogni mossa, l'agente non scrive nulla.
• Lavoro quotidiano: preset Auto (on-request + workspace-write), nessun flag da ricordare.
• Automazioni e CI: never con la sandbox più stretta che il task consente.
• Task lunghi non presidiati: on-request + approvals_reviewer = "auto_review" come via di mezzo.
• Verifica sempre: /status per la configurazione attiva, /permissions per cambiarla in sessione.

Altri articoli del blog