Codex e MCP: immagini e video da un solo config.toml

Un server MCP per Codex è una cassetta degli attrezzi esterna che l'agente di sviluppo di OpenAI può chiamare da tutte e tre le sue interfacce insieme: la CLI, l'estensione IDE e la scheda Codex nell'app desktop di ChatGPT. Un blocco TOML, e un agente che di solito modifica codice ottiene capacità che i suoi modelli non hanno di serie, compresa la generazione di immagini e video. Codex fa refactoring e lancia test tutto il giorno, ma nessun modello dietro di lui sa consegnarti un MP4. Aggiungi un server di generazione e «fai una clip promozionale per le note di rilascio» diventa un'istruzione da terminale che finisce con un file vero.

Ecco tutto il setup, se sei venuto solo per questo. Crea una chiave API nel tuo profilo BananaBanana, poi aggiungi questo a ~/.codex/config.toml:

[mcp_servers.bananabanana]
url = "https://bananabanana.pro/api/mcp"
bearer_token_env_var = "BB_API_KEY"

Esporta BB_API_KEY=bb_live_YOUR_KEY nel tuo ambiente e riavvia Codex. Tutto qui: nessun processo server locale, nessun progetto cloud tuo, nessun abbonamento. Le immagini partono da $0.03 e i video da $0.10, addebitati su un saldo prepagato. Il video demo più sotto è stato generato proprio tramite questo endpoint, su una chiave reale, mentre scrivevo il testo, e il conto media completo di $1.03 per questo articolo è dettagliato alla fine.

Perché qui un solo file di config è tutta la storia

La maggior parte dei client MCP ti fa configurare ogni interfaccia per conto suo. Codex no, ed è la parte davvero piacevole. La documentazione MCP ufficiale di Codex lo dice in una frase: «L'app desktop di ChatGPT, Codex CLI e l'estensione IDE condividono questa configurazione». Incolli il blocco TOML una volta e gli stessi dieci tool di generazione ti seguono da una sessione di terminale a VS Code fino alla scheda Codex dell'app desktop.

Questo cambia lo scopo del server. In Cursor o in VS Code un tool per immagini serve soprattutto il repo che hai aperto. Con Codex il terminale stesso diventa una console per i media: puoi chiedere il render di un video da una semplice shell, senza nessun editor di mezzo, e controllarlo più tardi dall'app desktop. Per chi vive in tmux e tratta le app grafiche come ospiti occasionali, è la differenza tra «un plugin che ho configurato da qualche parte» e «un comando che uso davvero».

L'alternativa, come al solito, è far girare un server MCP locale con la tua chiave del provider a monte, con quote e fatturazione legate al tuo account cloud. Funziona. È anche un processo da tenere d'occhio. L'endpoint remoto gira già dalla nostra parte, sulla stessa pipeline del generatore web BananaBanana, e l'unica credenziale è una chiave bb_live_ revocabile.

Come si collega Codex a un server MCP?

I dettagli della config qui sotto sono verificati sulla documentazione MCP ufficiale di Codex all'11 luglio 2026 (OpenAI l'ha spostata di recente da developers.openai.com a learn.chatgpt.com, quindi non stupirti del reindirizzamento).

Primo, registrati e apri Profilo → Chiavi API MCP. La chiave viene mostrata una sola volta e da noi è salvata come hash, quindi copiala subito. I nuovi account partono con $0.20 di saldo, che bastano per sei immagini di prova sul modello più economico.

Secondo, aggiungi il blocco TOML dall'inizio di questo articolo a ~/.codex/config.toml, creando il file se non esiste. La tabella [mcp_servers.bananabanana] accetta un url per qualsiasi server Streamable HTTP e bearer_token_env_var per l'autenticazione: Codex legge la variabile d'ambiente indicata all'avvio e invia il suo valore come header Authorization. La chiave non tocca mai il file, quindi il file resta condivisibile, anche nei repo di dotfiles. La nostra pagina del server MCP riporta questo snippet insieme a una tabella di compatibilità per ogni client che abbiamo verificato:

Terzo, esporta la variabile e riavvia. Nella CLI, codex elenca i tool del server appena si connette; chiedigli di «chiamare list_models su bananabanana» e dovresti ricevere i prezzi aggiornati per dieci tool, da list_models a list_generations. L'estensione IDE e l'app desktop di ChatGPT leggono la stessa config al prossimo avvio, senza passaggi in più.

Un avviso onesto sull'app desktop su macOS: un'applicazione grafica lanciata dal Dock non legge il tuo .zshrc, quindi un export che funziona nel terminale può semplicemente non esistere per ChatGPT. Se i tool compaiono nella CLI ma l'autenticazione fallisce nell'app desktop, la causa è quasi sempre questa. launchctl setenv BB_API_KEY bb_live_… la risolve, anche se sa di ripiego: perché lo è.

I connettori di ChatGPT possono usare la stessa chiave?

Risposta breve: ora sì, ed è bene essere precisi sul perché. ChatGPT ha un suo sistema di connettori (Settings → Connectors, dietro l'interruttore della modalità sviluppatore nei piani a pagamento) che aggiunge server MCP alla chat normale invece che a Codex. Quei connettori si autenticano tramite flussi OAuth. Dal 1° agosto 2026 il nostro endpoint parla OAuth 2.1 oltre alle chiavi Bearer, quindi ora anche la semplice chat di ChatGPT è un client supportato. La distinzione che resta: le interfacce di Codex (CLI, IDE, la scheda Codex nell'app desktop) funzionano oggi tramite config.toml, mentre i connettori lato chat passano dal flusso OAuth. La tabella di compatibilità segue la situazione client per client, con le date.

Caso d'uso: un video promozionale di prodotto senza aprire nessuna app

Lo scenario attorno a cui è costruito questo articolo: giorno di rilascio, il changelog ha bisogno di una breve clip promozionale e tu preferiresti non uscire dal terminale. Chiedi a Codex un video in stile prodotto, lui compone un prompt cinematografico e chiama generate_video. Il tool non addebita mai nulla alla prima chiamata; restituisce un preventivo, e l'agente ripete la chiamata accettando l'importo esatto. Questa è la traccia reale della mia sessione:

→ generate_video {"prompt": "Cinematic product promo shot: matte pearl-white
   wireless earbuds in an open charging case on a slowly rotating dark
   pedestal, dramatic rim lighting in violet and warm amber, soft haze,
   slow dolly-in from a slightly low angle, shallow depth of field,
   premium tech commercial style", "model": "veo-3.1-fast",
   "duration": 8, "resolution": "720p"}
← {"status": "confirmation_required", "quoted_cost_usd": 0.70,
   "message": "This video costs $0.70. Nothing has been charged."}
→ generate_video {..., "confirm_cost": 0.70}
← {"job_id": "cmrgrpxgf0002mk7fvfepg82j", "status": "processing",
   "cost_charged_usd": 0.70, "balance_remaining_usd": 1553.37}
→ get_result {"job_id": "cmrgrpxgf0002mk7fvfepg82j", "wait_seconds": 30}
← {"status": "completed", "files": [{"url": "https://…/api/files/…"}]}

Due minuti e quindici secondi dalla conferma al file finito a 720p. Ecco esattamente quella clip, generata da Veo 3.1 Fast, primo tentativo, nessuna rigenerazione:

La struttura del prompt segue lo schema della nostra guida ai prompt per Veo 3.1: soggetto, azione, luce, movimento di camera, comportamento dell'obiettivo, stile. Poi Codex scarica il file dall'URL firmato (valido 24 ore; una nuova chiamata a get_result lo rigenera) nella cartella che indichi e può perfino scrivere il markup <video> per la pagina del changelog.

Un'avvertenza onesta sul risultato: $0.70 comprano la versione senza audio. L'audio nativo sulla stessa clip costa $1.00, e Omni Flash con audio costa $0.10 al secondo, cioè $0.80 per una clip della stessa durata. Per un loop muto in autoplay su una landing page la versione senza audio è comunque proprio quello che ti serve; per un montaggio social probabilmente pagherai i trenta centesimi in più.

Le immagini funzionano allo stesso modo, senza il passaggio di conferma, perché una singola immagine costa abbastanza poco da lanciarla e basta: generate_image con un prompt restituisce un job id, e get_result ti ridà il file più una piccola anteprima inline che Codex può guardare.

Stranezze di Codex da conoscere prima di contarci

Raccolte mentre testavo il setup qui sopra, più o meno nell'ordine in cui ti daranno problemi.

1. La CLI non scrive questa config al posto tuo. codex mcp add esiste, ma secondo la documentazione ufficiale non ha un'opzione per il bearer token sui server HTTP; il comando è pensato per server stdio locali e login OAuth (codex mcp login). Per un server remoto autenticato con chiave modifichi ~/.codex/config.toml a mano. Trenta secondi di lavoro, ma se ti aspettavi l'esperienza da una riga di claude mcp add --header, è qui che Codex è diverso.

2. È TOML, e la tabella si chiama mcp_servers. Snake_case, parentesi quadre, niente JSON. Le config copiate dalla documentazione di Cursor o di Claude (mcpServers, parentesi graffe) non vengono lette, e gli errori TOML in questo file tendono a fallire in silenzio invece che in modo evidente. Se il server non compare mai, lancia codex da un terminale e guarda l'output di avvio prima di sospettare altro.

3. Per i segreti c'è un campo giusto e uno sbagliato ma invitante. bearer_token_env_var tiene la chiave fuori dal file. L'alternativa, la mappa http_headers, accetta valori statici, cioè una chiave bb_live_ in chiaro dentro un file che gli strumenti di sincronizzazione dei dotfiles adorano pubblicare. C'è anche env_http_headers per header personalizzati presi da variabili d'ambiente. La mia regola: bearer_token_env_var sempre, http_headers mai per qualcosa di segreto.

4. Il timeout predefinito dei tool è di 60 secondi, e va bene, ma solo per come funziona il polling. Di default Codex dà a ogni chiamata di tool tool_timeout_sec = 60. Un job video richiede da uno a dieci minuti, il che sembra un conflitto, solo che generate_video restituisce subito un job id e get_result fa long polling al massimo per 30 secondi a chiamata. Ogni singola chiamata resta comodamente sotto il limite; l'agente fa semplicemente qualche polling in più. Non «correggerlo» alzando il timeout a 600: non ti serve, e un server davvero bloccato fermerebbe poi l'agente per dieci minuti.

5. Il comportamento di approvazione si configura per server, e dove girano soldi ci vuole prompt. Secondo la documentazione, il campo default_tools_approval_mode accetta i valori auto, prompt, writes e approve. Per un server dove diversi tool spendono dollari veri a ogni chiamata, terrei attiva la richiesta di conferma e approverei le chiamate una per una; i tool gratuiti (list_models, get_account, get_result) sono quelli da mettere in allowlist, se il tuo setup supporta decisioni per singolo tool. I video hanno comunque un secondo lucchetto dalla nostra parte: oltre il preventivo non viene addebitato nulla senza un confirm_cost esplicito.

Quanto sono costati i media demo di questo articolo?

Prezzi standard per generazione, gli stessi numeri che list_models comunica all'agente, nessuno sconto interno:

Il video è riuscito al primo tentativo, cosa su cui non conterei ogni volta; le riprese in stile prodotto perdonano, tutto ciò che ha mani o testo leggibile no. Per quelle metti in conto una rigenerazione.

Se usi già questo server in un altro client, l'unica parte nuova è il blocco TOML qui sopra: stessa chiave, stesso saldo, stessa cronologia delle generazioni ovunque. Se parti da zero, la guida per Claude Code copre altri quattro casi d'uso che si trasferiscono a Codex quasi parola per parola. Crea una chiave e chiedi a Codex il tuo primo render.

FAQ

Codex supporta server MCP remoti con autenticazione Bearer?

Sì, nativamente. Un server remoto è una tabella [mcp_servers.<name>] in ~/.codex/config.toml con un campo url, e bearer_token_env_var indica la variabile d'ambiente il cui valore Codex invia come header Authorization. Verificato sulla documentazione MCP ufficiale di Codex l'11 luglio 2026. È supportato anche OAuth (è la modalità auth predefinita per i server che lo offrono), ma un setup con chiave statica non richiede altro che quelle due righe.

La config MCP è davvero condivisa tra Codex CLI, l'estensione IDE e ChatGPT desktop?

Sì. La documentazione di Codex dice che l'app desktop di ChatGPT, Codex CLI e l'estensione IDE condividono la configurazione di config.toml. In pratica l'unica cosa che non si trasferisce da sola è la variabile d'ambiente: gli export della shell sono visibili alla CLI, mentre un'app desktop lanciata dal Dock ha bisogno della variabile impostata a livello di sistema operativo (launchctl setenv su macOS), altrimenti fallirà l'autenticazione con la stessa identica config.

Posso aggiungere il server con codex mcp add invece di modificare il file?

Non per questo tipo di server. La documentazione non prevede un flag per il bearer token in codex mcp add per i server HTTP, quindi un endpoint remoto autenticato con chiave significa modificare ~/.codex/config.toml a mano. Il lato buono della modifica a mano è che il risultato è esplicito e versionabile; il blocco è di tre righe, e la chiave resta nell'ambiente invece che nel file.

Perché la mia chiave bb_live_ non funziona nelle impostazioni Connectors di ChatGPT?

Perché è un'altra superficie di integrazione. I connettori nella chat di ChatGPT (web e desktop, dietro l'interruttore della modalità sviluppatore) autenticano i server MCP tramite OAuth, non con chiavi API incollate. Le interfacce di Codex invece leggono config.toml e con la chiave funzionano bene. Il nostro supporto a OAuth 2.1 è arrivato il 1° agosto 2026, quindi ora anche i connettori lato chat sono una strada supportata, solo tramite il flusso OAuth invece che con la chiave; la tabella dei client segue lo stato attuale.

Codex può generare video, e quanto costa?

Sì, con una conferma del costo obbligatoria. generate_video restituisce sempre prima un preventivo in USD e non addebita nulla; l'agente ripete la chiamata con confirm_cost pari all'importo preventivato per avviare il render. I prezzi vanno da $0.10 per una clip Veo 3.1 Lite di 4 secondi a 720p senza audio, passando per i $0.70 della demo Veo 3.1 Fast da 8 secondi di questo articolo, fino a $4.40 per un render Veo 3.1 di fascia alta in 4K con audio; Omni Flash con audio costa $0.10 al secondo, quindi $0.30–$1.00 a clip. Le generazioni fallite vengono rimborsate in automatico.