Codex MCP einrichten: Bilder und Video aus einer config.toml

Ein MCP-Server für Codex ist ein externer Werkzeugkasten, den OpenAIs Coding-Agent von allen drei Oberflächen gleichzeitig aufrufen kann: aus der CLI, aus der IDE-Erweiterung und aus dem Codex-Tab in der ChatGPT-Desktop-App. Ein TOML-Block, und ein Agent, der normalerweise Code bearbeitet, bekommt Fähigkeiten, die seine Modelle nicht mitbringen – Bild- und Videogenerierung eingeschlossen. Codex refaktoriert und lässt den ganzen Tag Tests laufen, aber kein Modell dahinter kann dir eine MP4 liefern. Füg einen Generierungsserver hinzu, und „mach einen Promo-Clip für die Release Notes“ wird zu einer Terminal-Anweisung, an deren Ende eine echte Datei steht.

Hier das komplette Setup, falls du nur deswegen hier bist. Erstelle einen API-Schlüssel in deinem BananaBanana-Profil und füge Folgendes in ~/.codex/config.toml ein:

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

Exportiere BB_API_KEY=bb_live_YOUR_KEY in deiner Umgebung und starte Codex neu. Das war's: kein lokaler Serverprozess, kein eigenes Cloud-Projekt, kein Abo. Bilder kosten ab $0.03 vom Prepaid-Guthaben, Video ab $0.10. Das Demovideo weiter unten habe ich genau über diesen Endpunkt mit einem echten Schlüssel generiert, während ich den Text geschrieben habe, und die komplette Medienrechnung von $1.03 für diesen Artikel ist am Ende aufgeschlüsselt.

Warum hier eine einzige Config-Datei die ganze Geschichte ist

Bei den meisten MCP-Clients konfigurierst du jede Oberfläche einzeln. Codex nicht, und das ist wirklich das Angenehme daran. Die offizielle Codex-MCP-Dokumentation sagt es in einem Satz: „Die ChatGPT-Desktop-App, Codex CLI und die IDE-Erweiterung teilen sich diese Konfiguration.“ Füg den TOML-Block einmal ein, und dieselben zehn Generierungs-Tools begleiten dich von der Terminal-Session über VS Code bis in den Codex-Tab der Desktop-App.

Das verändert, wofür der Server da ist. In Cursor oder VS Code dient ein Bild-Tool vor allem dem Repo, das gerade offen ist. Mit Codex wird das Terminal selbst zur Medienkonsole: Du kannst aus einer nackten Shell ein Video-Rendering anstoßen, ganz ohne Editor, und später in der Desktop-App nachsehen, wie weit es ist. Für jemanden, der in tmux lebt und GUI-Apps als gelegentliche Gäste behandelt, ist das der Unterschied zwischen „ein Plugin, das ich irgendwo eingerichtet habe“ und „ein Befehl, den ich wirklich benutze“.

Die Alternative ist wie üblich ein lokaler MCP-Server mit deinem eigenen Schlüssel beim Upstream-Anbieter, mit Quoten und Abrechnung auf deinem eigenen Cloud-Konto. Das funktioniert. Es ist aber auch ein Prozess, den du betreuen musst. Der Remote-Endpunkt läuft bereits bei uns, auf derselben Pipeline wie der BananaBanana-Webgenerator, und deine einzige Zugangsinformation ist ein widerrufbarer bb_live_-Schlüssel.

Wie verbindest du Codex mit einem MCP-Server?

Die Config-Details unten sind mit der offiziellen Codex-MCP-Dokumentation abgeglichen, Stand 11. Juli 2026 (OpenAI hat sie kürzlich von developers.openai.com nach learn.chatgpt.com umgezogen, wundere dich also nicht über die Weiterleitung).

Erstens: Registriere dich und öffne Profil → MCP-API-Schlüssel. Der Schlüssel wird nur einmal angezeigt und bei uns gehasht gespeichert, kopiere ihn also sofort. Neue Konten bekommen $0.20 Startguthaben, das reicht für sechs Testbilder mit dem günstigsten Modell.

Zweitens: Füg den TOML-Block vom Anfang dieses Artikels in ~/.codex/config.toml ein und leg die Datei an, falls es sie noch nicht gibt. Die Tabelle [mcp_servers.bananabanana] nimmt eine url für jeden Streamable-HTTP-Server und bearer_token_env_var für die Authentifizierung: Codex liest die genannte Umgebungsvariable beim Start und schickt ihren Wert als Authorization-Header. Der Schlüssel landet nie in der Datei, die Datei bleibt also teilbar, auch in Dotfiles-Repos. Auf unserer MCP-Server-Seite steht dieses Snippet neben einer Kompatibilitätstabelle für alle Clients, die wir geprüft haben:

Drittens: Exportiere die Variable und starte neu. In der CLI listet codex die Tools des Servers auf, sobald die Verbindung steht; bitte es, „call list_models on bananabanana“ auszuführen, und du solltest aktuelle Preise für zehn Tools zurückbekommen, von list_models bis list_generations. Die IDE-Erweiterung und die ChatGPT-Desktop-App übernehmen dieselbe Config beim nächsten Start ohne weitere Schritte.

Eine ehrliche Warnung zur Desktop-App auf macOS: Eine GUI-Anwendung, die aus dem Dock startet, liest deine .zshrc nicht, ein export, das im Terminal funktioniert, existiert für ChatGPT also womöglich stillschweigend nicht. Wenn die Tools in der CLI auftauchen, die Authentifizierung in der Desktop-App aber scheitert, ist das fast immer die Ursache. launchctl setenv BB_API_KEY bb_live_… behebt das – auch wenn es sich wie ein Workaround anfühlt, weil es einer ist.

Können ChatGPTs eigene Connectors denselben Schlüssel nutzen?

Kurze Antwort: inzwischen ja, und es lohnt sich, genau zu sein, warum. ChatGPT hat ein eigenes Connector-System (Settings → Connectors, in bezahlten Tarifen hinter dem Schalter für den Entwicklermodus), das MCP-Server zum normalen Chat hinzufügt statt zu Codex. Diese Connectors authentifizieren sich über OAuth-Flows. Unser Endpunkt spricht seit dem 1. August 2026 neben Bearer-Schlüsseln auch OAuth 2.1, der normale ChatGPT-Chat ist also inzwischen ebenfalls ein unterstützter Client. Die verbleibende Trennlinie: Codex-Oberflächen (CLI, IDE, der Codex-Tab in der Desktop-App) funktionieren heute über config.toml, Connectors im Chat laufen stattdessen über den OAuth-Flow. Die Kompatibilitätstabelle hält das pro Client fest, mit Datum.

Anwendungsfall: ein Produkt-Promovideo, ohne eine einzige App zu öffnen

Das Szenario, um das dieser Artikel gebaut ist: Release-Tag, dein Changelog braucht einen kurzen Promo-Clip, und du willst das Terminal lieber nicht verlassen. Du bittest Codex um ein Video im Produktstil, es formuliert einen filmischen Prompt und ruft generate_video auf. Beim ersten Aufruf berechnet das Tool nie etwas; es liefert ein Angebot, und der Agent wiederholt den Aufruf und akzeptiert dabei genau diesen Betrag. Das ist der echte Trace aus meiner Session:

→ 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/…"}]}

Zwei Minuten und fünfzehn Sekunden von der Bestätigung bis zur fertigen 720p-Datei. Hier genau dieser Clip, generiert von Veo 3.1 Fast, erster Versuch, ohne Neugenerierung:

Die Prompt-Struktur folgt dem Muster aus unserem Veo-3.1-Prompt-Leitfaden: Motiv, Handlung, Licht, Kamerabewegung, Objektivverhalten, Stil. Anschließend holt Codex die Datei über die signierte URL (24 Stunden gültig; ein neuer get_result-Aufruf stellt sie neu aus) in den Ordner, den du nennst, und kann sogar das <video>-Markup für deine Changelog-Seite schreiben.

Ein ehrlicher Vorbehalt zum Ergebnis: Für $0.70 bekommst du die Version ohne Ton. Nativer Ton für denselben Clip kostet $1.00, und Omni Flash mit Ton rechnet $0.10 pro Sekunde ab – $0.80 für einen Clip gleicher Länge. Für eine stumme Autoplay-Schleife auf einer Landingpage willst du ohnehin genau die Version ohne Ton; für einen Social-Schnitt zahlst du wahrscheinlich die dreißig Cent extra.

Bilder funktionieren genauso, nur ohne Bestätigungsschritt, denn einzelne Bilder sind günstig genug, um sie einfach laufen zu lassen: generate_image mit einem Prompt liefert eine Job-ID, get_result gibt die Datei plus eine kleine Inline-Vorschau zurück, die Codex sich ansehen kann.

Codex-Eigenheiten, die du kennen solltest, bevor du dich darauf verlässt

Gesammelt beim Testen des Setups oben, ungefähr in der Reihenfolge, in der sie dich erwischen.

1. Die CLI schreibt dir diese Config nicht. codex mcp add gibt es, aber laut offizieller Doku hat es für HTTP-Server keine Option für Bearer-Token; der Befehl zielt auf lokale stdio-Server und OAuth-Logins (codex mcp login). Für einen Remote-Server mit Schlüssel-Authentifizierung bearbeitest du ~/.codex/config.toml von Hand. Dreißig Sekunden Arbeit, aber wenn du den Einzeiler-Komfort von claude mcp add --header erwartet hast, unterscheidet sich Codex genau hier.

2. Es ist TOML, und die Tabelle heißt mcp_servers. Snake_case, eckige Klammern, kein JSON. Configs, die aus der Cursor- oder Claude-Doku kopiert sind (mcpServers, geschweifte Klammern), werden nicht geparst, und TOML-Fehler in dieser Datei scheitern eher leise als laut. Taucht der Server nie auf, starte codex aus einem Terminal und schau dir die Startausgabe an, bevor du irgendetwas anderes verdächtigst.

3. Für Secrets gibt es ein richtiges Feld und ein verlockend falsches. bearer_token_env_var hält den Schlüssel aus der Datei heraus. Die Alternative, die http_headers-Map, nimmt statische Werte – also einen bb_live_-Schlüssel im Klartext in einer Datei, die Dotfile-Sync-Tools nur zu gern veröffentlichen. Außerdem gibt es env_http_headers für eigene Header aus Umgebungsvariablen. Meine Regel: immer bearer_token_env_var, nie http_headers für irgendetwas Geheimes.

4. Das Standard-Timeout für Tools liegt bei 60 Sekunden, und das passt – aber nur wegen der Art, wie das Polling funktioniert. Codex gibt jedem Tool-Aufruf standardmäßig tool_timeout_sec = 60. Ein Video-Job dauert eine bis zehn Minuten, was nach einem Konflikt klingt, nur dass generate_video sofort eine Job-ID zurückgibt und get_result pro Aufruf höchstens 30 Sekunden lang per Long-Polling wartet. Jeder einzelne Aufruf bleibt bequem unter dem Limit; der Agent fragt einfach ein paarmal nach. „Repariere“ das nicht, indem du das Timeout auf 600 hochsetzt – du brauchst es nicht, und ein tatsächlich hängender Server würde den Agenten dann zehn Minuten blockieren.

5. Das Freigabeverhalten lässt sich pro Server einstellen, und bei Geld gehört prompt dorthin. Das Feld default_tools_approval_mode akzeptiert laut Doku die Werte auto, prompt, writes und approve. Bei einem Server, auf dem mehrere Tools pro Aufruf echte Dollar ausgeben, würde ich die Nachfrage anlassen und Aufrufe einzeln freigeben; die kostenlosen Tools (list_models, get_account, get_result) sind die, die sich für eine Allowlist lohnen, falls dein Setup Entscheidungen pro Tool unterstützt. Für Video gibt es bei uns ohnehin eine zweite Sperre: Ohne ausdrückliches confirm_cost wird nichts über ein Angebot hinaus berechnet.

Was haben die Demo-Medien dieses Artikels gekostet?

Normale Preise pro Generierung, dieselben Zahlen, die list_models dem Agenten meldet, kein Mitarbeiterrabatt:

Das Video hat beim ersten Versuch geklappt, darauf würde ich mich aber nicht jedes Mal verlassen: Aufnahmen im Produktstil verzeihen viel, alles mit Händen oder lesbarem Text nicht. Plane dafür eine Neugenerierung ein.

Wenn du diesen Server schon in einem anderen Client nutzt, ist der TOML-Block oben das einzig Neue: gleicher Schlüssel, gleiches Guthaben, überall derselbe Generierungsverlauf. Fängst du bei null an, zeigt die Anleitung für Claude Code vier weitere Anwendungsfälle, die sich fast wortgleich auf Codex übertragen lassen. Erstelle einen Schlüssel und bitte Codex um dein erstes Rendering.

FAQ

Unterstützt Codex Remote-MCP-Server mit Bearer-Authentifizierung?

Ja, nativ. Ein Remote-Server ist eine [mcp_servers.<name>]-Tabelle in ~/.codex/config.toml mit einem url-Feld, und bearer_token_env_var nennt die Umgebungsvariable, deren Wert Codex als Authorization-Header sendet. Geprüft gegen die offizielle Codex-MCP-Doku am 11. Juli 2026. OAuth wird ebenfalls unterstützt (es ist der Standard-auth-Modus für Server, die es anbieten), aber ein Setup mit statischem Schlüssel braucht nichts außer diesen zwei Zeilen.

Teilen sich Codex CLI, die IDE-Erweiterung und ChatGPT Desktop wirklich dieselbe MCP-Config?

Ja. Die Codex-Dokumentation sagt, dass die ChatGPT-Desktop-App, Codex CLI und die IDE-Erweiterung sich die Konfiguration in config.toml teilen. In der Praxis überträgt sich nur eines nicht automatisch: die Umgebungsvariable. Deine Shell-Exports sieht die CLI, eine aus dem Dock gestartete Desktop-App braucht die Variable dagegen auf Betriebssystemebene (launchctl setenv auf macOS), sonst scheitert die Authentifizierung mit genau derselben Config.

Kann ich den Server mit codex mcp add hinzufügen, statt die Datei zu bearbeiten?

Nicht für diese Art von Server. Laut Doku hat codex mcp add für HTTP-Server kein Flag für Bearer-Token, ein Remote-Endpunkt mit Schlüssel-Authentifizierung bedeutet also, dass du ~/.codex/config.toml selbst bearbeitest. Der Vorteil der Handarbeit: Das Ergebnis ist explizit und versionierbar. Der Block hat drei Zeilen, und der Schlüssel bleibt in der Umgebung statt in der Datei.

Warum funktioniert mein bb_live_-Schlüssel nicht in den Connector-Einstellungen von ChatGPT?

Weil das eine andere Integrationsoberfläche ist. Connectors im ChatGPT-Chat (Web und Desktop, hinter dem Schalter für den Entwicklermodus) authentifizieren MCP-Server über OAuth, nicht über eingefügte API-Schlüssel. Codex-Oberflächen lesen stattdessen config.toml und funktionieren mit dem Schlüssel problemlos. Unsere OAuth-2.1-Unterstützung ist seit dem 1. August 2026 live, Connectors im Chat sind also inzwischen ebenfalls ein unterstützter Weg – nur eben über den OAuth-Flow statt über den Schlüssel; die Client-Tabelle zeigt den aktuellen Stand.

Kann Codex Videos generieren, und was kostet das?

Ja, mit verpflichtender Kostenbestätigung. generate_video liefert immer zuerst ein Angebot in USD und berechnet nichts; der Agent wiederholt den Aufruf mit confirm_cost in Höhe des angebotenen Betrags, um das Rendering zu starten. Die Preise reichen von $0.10 für einen 4-Sekunden-Clip ohne Ton in 720p auf Veo 3.1 Lite über $0.70 für die 8-Sekunden-Demo auf Veo 3.1 Fast in diesem Artikel bis $4.40 für ein Top-Rendering auf Veo 3.1 in 4K mit Ton; Omni Flash mit Ton kostet $0.10 pro Sekunde, also $0.30–$1.00 pro Clip. Fehlgeschlagene Generierungen werden automatisch erstattet.