Passa al contenuto principale

Codex Agent Plugins e federazione dei cataloghi (v0.147.0): la guida pratica

Intermedio

Il 7 agosto 2026 OpenAI ha rilasciato Codex CLI v0.147.0. Quasi tutta la copertura l'ha ridotta a un unico bullet ("adesso ci sono i plugin, figo"). La release vera cambia quattro cose in un colpo solo, e tre di queste rompono silenziosamente script che probabilmente hai in CI oggi: gli Agent Plugin portabili sostituiscono le installazioni ad-hoc di skill e si fondono su un catalogo a quattro livelli; un nuovo flag --approve-for-me sembra "approva tutto in automatico" ma non lo è; la vecchia scorciatoia --full-auto è rimossa; e Codex ora offre l'opt-in a MCP 2026-07-28 con avvio dei server non bloccante. Ognuno di questi punti ha un'insidia che è bene conoscere prima di aggiornare.

Questa pagina è la guida sul campo pratica per chi già conosce le Skill di Claude Code, i subagent e MCP — e vuole solo sapere cosa fa davvero la versione di Codex, in cosa si differenzia e cosa cambiare nel flusso di lunedì mattina.

What you'll learn
  • Sapere esattamente cosa è arrivato in Codex CLI v0.146.1 (5 ago) e v0.147.0 (7 ago), e perché insieme contano
  • Capire il catalogo a quattro livelli — local, personal, workspace, remote — e le regole di merge/dedup che decidono quale plugin vince davvero
  • Leggere correttamente `--approve-for-me`: è un passaggio di revisione, non un bypass della sandbox; la sandbox a livello OS resta attiva
  • Migrare via dal flag `--full-auto` rimosso prima che la prossima run di CI fallisca in silenzio
  • Decidere quando fare opt-in a MCP 2026-07-28 in Codex — e cosa ti dà davvero l'avvio dei server non bloccante

Il quadro delle due release: 0.146.1 poi 0.147.0​

Il rilascio di agosto sono in realtà due release a 48 ore di distanza, e leggerle come una sola confonde cosa è cambiato.

Guided walkthrough1 of 3
  1. Una point release silenziosa, ma ha cambiato la *postura di partenza* per i modelli marchiati cyber-capable (la stessa classe che comprende GPT-5.6-Cyber). I default di auto-approvazione si stringono: rete, lettura di credenziali e gestione dei processi ora richiedono un whitelisting esplicito invece di appoggiarsi alla vecchia baseline permissiva. Codex ha anche iniziato a spiegare i cambiamenti di permesso nel terminale — vedi *perché* una richiesta è stata bloccata, non solo che lo è stata.

Agent Plugin portabili: cosa è cambiato a livello di file​

Codex ha avuto le Skill — una cartella di SKILL.md + fratelli che qualsiasi agente conforme può caricare — per tutto il 2026. La v0.147.0 aggiunge sopra uno strato di package: gli Agent Plugin. Un plugin è un'unità distribuibile che può impacchettare una o più skill, server MCP, prompt e configurazione in un singolo artefatto che installi per nome da un catalogo. Le skill restano portabili tra agenti; i plugin sono lo strato di packaging e distribuzione proprio di Codex.

Lo shift importante è come vengono scoperti. Prima della v0.147.0 copiavi a mano una cartella di skill nel tuo progetto o nella tua cartella personale. Dopo la v0.147.0 Codex guarda in quattro posti e fonde i risultati.

Il catalogo a quattro livelli — e la regola di merge che decide chi vince​

Codex cerca in quattro cataloghi in un ordine di precedenza fisso. Quando due cataloghi contengono un plugin con lo stesso nome, vince quello a precedenza più alta e la copia a precedenza più bassa viene nascosta.

LivelloPosizioneChi lo possiedeUso tipico
1. Local.codex/plugins/ dentro il repoCommittato nel progettoTooling specifico del repo; viaggia con il branch
2. Personal~/.codex/plugins/Solo tu, sulla tua macchinaI tuoi plugin fatti a mano o sperimentali
3. WorkspaceAmbito workspace condiviso col teamIl tuo teamConvenzioni condivise, flussi di review, script di deploy
4. RemoteRoot di marketplace che configuriVendor + communityPlugin pubblici da marketplace.openai.com o registry interni

Regola di merge: i risultati sono deduplicati per nome del plugin, e viene mostrata per prima la copia a precedenza più alta. Un plugin terraform-drift committato in .codex/plugins/terraform-drift/ nel tuo repo oscura silenziosamente la versione dello stesso nome nel catalogo remoto. Questo è voluto — i repo devono poter congelare una versione nota come buona — ma è la causa numero uno di "perché il mio plugin si comporta diversamente da come dicono i docs?" dopo un aggiornamento.

:::tip Leggi codex plugin list prima di debuggare il comportamento codex plugin list mostra i plugin installati con il tier di provenienza da cui ognuno è stato risolto. Se un plugin sta facendo qualcosa di sorprendente, questo è il primo comando da lanciare — la versione che stai usando potrebbe non essere quella che pensi. :::

Configurare i cataloghi — il config.toml minimo​

Gli endpoint di marketplace e il comportamento di auto-update si impostano nel config.toml di Codex. Il default v0.147.0 mantiene auto_update = false, che è la scelta giusta per la riproducibilità ma significa che devi lanciare gli update deliberatamente.

# ~/.codex/config.toml
[plugins]
enabled = true
marketplace_roots = [
  "https://plugins.internal.example.com",
  "https://marketplace.openai.com"
]
auto_update = false
update_check_interval_hours = 24

Il limite di voci del catalogo è stato alzato da 512 a 2.048 in v0.147.0 — un numero piccolo che conta se punti Codex a un grande registry interno. Sotto 512, i plugin oltre il tetto venivano troncati silenziosamente dai risultati di ricerca; i team enterprise ci sbattevano abbastanza spesso che OpenAI ha alzato il soffitto.

Lavorare con i plugin — i comandi di tutti i giorni​

Sfoglia il catalogo fuso in un picker interattivo

/plugins

Cerca su tutti e quattro i tier insieme

codex plugin marketplace search "terraform"

Installa per nome il match a precedenza più alta

codex plugin install terraform-drift

Vedi cosa è installato E da quale tier arriva ciascuno

codex plugin list

Aggiorna ogni plugin installato (opt-in — auto_update di default è off)

codex plugin update

Tre hardening di sicurezza dentro l'install dei plugin​

Il percorso di install dei plugin in v0.147.0 ha silenziosamente stretto tre cose — tutte da conoscere perché cambiano cosa significa "l'install funziona".

Guided walkthrough1 of 3
  1. Se un pacchetto di plugin contiene un symlink, Codex lo salta invece di seguirlo. Questo blocca un'intera classe di attacchi di path-traversal — un plugin malevolo non può più linkare `plugin/config` → `/etc/passwd`. Il compromesso: i pacchetti legittimi che usavano symlink per asset condivisi devono inlinare tali file.

--approve-for-me: cosa fa davvero (e cosa no)​

Il nome si legge come "approva ogni richiesta in automatico". Non è ciò che fa il flag. --approve-for-me instrada le richieste di approvazione attraverso un passaggio di revisione automatico che giudica ogni richiesta rispetto alla tua sandbox attiva e alla configurazione di approval-policy. Se la policy dice "sì, è dentro la whitelist", la richiesta procede senza prompt. Se la policy dice "no o non è chiaro", la richiesta è rifiutata — semplicemente non ti viene chiesto in mezzo a una run.

Due cose che restano vere:

  • La sandbox a livello OS è comunque applicata. Su Linux via Bubblewrap; su macOS via la sandbox della piattaforma. --approve-for-me non può evadere dalla sandbox; può solo decidere se auto-rispondere ai prompt dentro di essa.
  • I modelli cyber-capable ereditano in automatico i default più sicuri di v0.146.1. L'accesso di rete, la lettura di credenziali e la gestione dei processi restano rifiutati salvo whitelisting esplicito, indipendentemente da cosa dica --approve-for-me.

Il modello mentale giusto: --approve-for-me trasforma il tuo file di policy nell'umano. Se la tua policy è larga, questo flag è pericoloso; se la tua policy è stretta, questo flag è il pezzo mancante per le run non presidiate.

Run interattiva — la policy giudica le approvazioni, la sandbox resta attiva

codex --approve-for-me --sandbox workspace-write "refactor auth and run tests"

Run exec (non interattiva) con un contratto di output strutturato

codex exec --approve-for-me --sandbox workspace-write \
--output-schema '{"type":"object","properties":{"passed":{"type":"boolean"}}}' \
"run the full test suite"

Una approval policy minima che si abbina sensatamente al flag:

# ~/.codex/config.toml
[approval_policy]
sandbox_mode = "workspace-write"

[approval_policy.network]
allowed = ["api.github.com", "registry.npmjs.org"]

Tutto ciò che non è in quella allow-list viene rifiutato — anche da --approve-for-me.

Il breaking change silenzioso: --full-auto è rimosso​

Se hai CI o Makefile che chiamano codex exec --full-auto, si rompono su v0.147.0. Il flag non c'è più. Il rimpiazzo è esplicito:

# Prima di v0.147.0 (ora rotto)
codex exec --full-auto "run tests"

# Sintassi v0.147.0
codex exec --sandbox workspace-write "run tests"

I due non sono identici: --full-auto combinava una scelta di sandbox e una scelta di approval-policy. La nuova forma richiede di dichiarare esplicitamente la sandbox, e se vuoi riavere la metà "non chiedermi", aggiungi --approve-for-me. Vale la pena fare grep di questo prima di aggiornare un runner condiviso.

MCP 2026-07-28 in Codex — tre cose che ci guadagni davvero​

Codex ha reso la nuova spec MCP opt-in in v0.147.0. Attivala quando un server su cui fai affidamento ha migrato; lasciala spenta altrimenti. Tre vincite concrete se giri l'interruttore:

  • Discovery paginato. I server che espongono 200+ tool non forzano più una lista gigantesca one-shot; il client scorre le pagine. La latenza al primo tool cala molto.
  • Richieste multi-round. Una singola operazione logica può abbracciare diversi round client↔server — pensa a un form interattivo, a una conferma in due step, o a una lettura di risorsa che ritorna un token di follow-up. Prima di 2026-07-28 andava tutto ingozzato in un unico payload.
  • Avvio dei server non bloccante. Codex non blocca più il proprio boot sui server MCP lenti. Un server che ci mette 4 secondi a scaldare congelava tutta la CLI; ora Codex parte, e il server viene marcato ready quando lo è.

Come questo si mappa su Claude Code, in una tabella​

Se il tuo istinto è Claude, questa è la tabella di traduzione per gli stessi concetti.

ConcettoCodex CLI (v0.147.0)Claude Code
Unità di istruzioni portabileSkill (cartella SKILL.md)Skill (cartella SKILL.md) — stesso standard aperto
Packaging / distribuzioneAgent Plugin (impacchetta skill, MCP, config)Marketplace di plugin + install di skill
Ambito di discoveryCatalogo a quattro livelli (local → personal → workspace → remote)Progetto + utente + marketplace
Auto-approvazione dentro la sandbox--approve-for-me + approval_policyPermessi in ~/.claude/settings.json
Applicazione della sandboxBubblewrap (Linux) / sandbox macOSSandbox con mascheramento delle credenziali
Server MCP a lunga durataAvvio non bloccante (MCP 2026-07-28)Avvio bloccante salvo opt-in
"Istruzioni nel repo".codex/plugins/, AGENTS.md.claude/, CLAUDE.md

La differenza pratica più grossa: il catalogo a quattro livelli di Codex con lo shadowing in-repo di .codex/plugins/ è più aggressivo del default di Claude Code. È una feature — un repo può fissare una versione di plugin ed essere sicuro che tutti girino su quella — ma significa che "ho aggiornato il plugin e non è cambiato niente" spesso è "il tuo repo ha fissato una copia più vecchia".

Una checklist di migrazione per team già su Codex​

Guided walkthrough1 of 6
  1. È la causa più comune di una CI verde che diventa rossa dopo che `codex --version` salta di release.

Quando i plugin di Codex battono i subagent di Claude — e quando no​

I plugin di Codex sono più forti quando l'unità di riuso è un pacchetto di workflow — un flusso di review, una sequenza di deploy, una passata di Terraform-drift — che vuoi spedire come singolo artefatto a un intero team, con versionamento e un marketplace dietro. Il catalogo a quattro livelli è genuinamente utile in organizzazioni che hanno bisogno di "il plugin di reviewer che spedisce il team di piattaforma, a meno che il mio repo non lo sovrascriva".

Il modello subagent-più-skill di Claude Code è più forte quando l'unità di riuso è un ruolo ("code-reviewer", "debugger") che si compone liberamente dentro una singola sessione interattiva, e quando vuoi che lo stesso file giri in ChatGPT, Cursor, Gemini CLI e Codex senza re-package. Le skill restano la primitiva più portabile; i plugin sono lo strato di distribuzione più potente.

La risposta pratica per la maggior parte dei team ad agosto 2026 è entrambi: tieni le skill come primitiva a livello di file così viaggiano tra agenti, e avvolgile in un Codex Agent Plugin quando ti serve il marketplace, la federazione dei cataloghi e il pinning.

Check yourself

0/4
  1. Due cataloghi contengono un plugin chiamato `terraform-drift`: uno committato in `.codex/plugins/` del repo, uno su `marketplace.openai.com`. Quale usa Codex?
  2. Lanci `codex exec --approve-for-me --sandbox workspace-write "install curl and hit a random URL"`. La tua approval policy consente solo `api.github.com`. Cosa succede?
  3. Il tuo Makefile di CI chiama ancora `codex exec --full-auto "run tests"`. Dopo l'aggiornamento a v0.147.0, il job fallisce. Qual è la fix minima che preserva l'intento originario?
  4. Quale feature di MCP 2026-07-28 risolve più direttamente 'Codex ci mette 4 secondi a partire perché un server MCP è lento a scaldarsi'?

Fonti e approfondimenti​