Zum Hauptinhalt springen

Codex Agent Plugins & Katalog-Föderation (v0.147.0): Der Praxis-Leitfaden

Fortgeschritten

Am 7. August 2026 veröffentlichte OpenAI Codex CLI v0.147.0. Die meiste Berichterstattung reduzierte es auf einen Bulletpoint ("Plugins jetzt, cool"). Das echte Release ändert vier Dinge gleichzeitig, und drei davon brechen still Skripte, die du wahrscheinlich heute in der CI hast: portable Agent Plugins ersetzen Ad-hoc-Skill-Installationen und werden über einen vierstufigen Katalog gemergt; ein neues --approve-for-me-Flag liest sich wie "alles automatisch genehmigen", ist es aber nicht; die alte --full-auto-Abkürzung ist entfernt; und Codex bietet jetzt opt-in MCP 2026-07-28 mit nicht-blockierendem Server-Start. Jedes hat einen Fallstrick, den man vor dem Upgrade kennen sollte.

Diese Seite ist der praktische Feldführer für Leser:innen, die Claude Code Skills, Subagents und MCP bereits verstehen — und einfach wissen wollen, was die Codex-Version wirklich tut, wo sie sich unterscheidet und was in einem Montagmorgen-Workflow zu ändern ist.

What you'll learn
  • Genau wissen, was in Codex CLI v0.146.1 (5. Aug) und v0.147.0 (7. Aug) veröffentlicht wurde und warum die beiden zusammen wichtig sind
  • Den vierstufigen Plugin-Katalog verstehen — lokal, persönlich, Workspace, remote — und die Merge-/Dedup-Regeln, die entscheiden, welches Plugin tatsächlich gewinnt
  • `--approve-for-me` richtig lesen: es ist ein Review-Pass, kein Sandbox-Bypass; die OS-Level-Sandbox bleibt an
  • Vom entfernten `--full-auto`-Flag migrieren, bevor dein nächster CI-Lauf still fehlschlägt
  • Entscheiden, wann man sich in Codex für MCP 2026-07-28 anmelden sollte — und was nicht-blockierender Server-Start bringt

Das Bild der zwei Releases: 0.146.1 dann 0.147.0​

Der August-Drop besteht eigentlich aus zwei Releases im Abstand von 48 Stunden, und sie als eines zu lesen verwischt, was sich geändert hat.

Guided walkthrough1 of 3
  1. Ein leises Point-Release, aber es änderte die *Ausgangshaltung* für Modelle, die als cyber-fähig markiert sind (dieselbe Klasse, zu der auch GPT-5.6-Cyber gehört). Auto-Approval-Defaults verschärfen sich: Netzwerk, Credential-Reads und Prozessverwaltung erfordern jetzt explizites Whitelisting, statt sich auf die ältere permissive Baseline zu stützen. Codex begann auch, Berechtigungsänderungen im Terminal zu erklären — du siehst *warum* eine Anfrage blockiert wurde, nicht nur, dass sie es war.

Portable Agent Plugins: was sich auf File-Ebene änderte​

Codex hatte für das ganze Jahr 2026 Skills — einen Ordner aus SKILL.md + Geschwisterdateien, den jeder konforme Agent laden kann. v0.147.0 fügt eine Package-Schicht darüber hinzu: Agent Plugins. Ein Plugin ist eine verteilbare Einheit, die ein oder mehrere Skills, MCP-Server, Prompts und Konfiguration in ein einziges Artefakt bündelt, das man per Name aus einem Katalog installiert. Skills bleiben portabel über Agents hinweg; Plugins sind die eigene Packaging- und Distributionsschicht von Codex.

Der wichtige Shift ist, wie sie gefunden werden. Vor v0.147.0 hast du ein Skill-Verzeichnis von Hand in dein Projekt oder deinen persönlichen Ordner kopiert. Nach v0.147.0 schaut Codex an vier Orten nach und mergt die Ergebnisse.

Der vierstufige Katalog — und die Merge-Regel, die entscheidet, wer gewinnt​

Codex durchsucht vier Kataloge in einer festen Vorrang-Reihenfolge. Wenn zwei Kataloge ein Plugin mit demselben Namen enthalten, gewinnt das mit höherer Priorität und die Kopie mit niedrigerer Priorität wird versteckt.

EbeneOrtWer besitzt esTypischer Einsatz
1. Lokal.codex/plugins/ im RepoIns Projekt committetRepo-spezifisches Tooling; wandert mit dem Branch
2. Persönlich~/.codex/plugins/Nur du, auf deinem RechnerDeine eigenen selbstgebauten oder experimentellen Plugins
3. WorkspaceTeam-shared Workspace-ScopeDein TeamGeteilte Konventionen, Review-Flows, Deploy-Skripte
4. RemoteMarketplace-Roots, die du konfigurierstVendors + CommunityÖffentliche Plugins von marketplace.openai.com oder internen Registrys

Merge-Regel: Ergebnisse werden nach Plugin-Namen dedupliziert, und die Kopie mit höchster Priorität wird zuerst angezeigt. Ein terraform-drift-Plugin, das in deinem Repo unter .codex/plugins/terraform-drift/ committet ist, überschattet still die Remote-Katalog-Version desselben Namens. Das ist so gewollt — Repos sollen eine bekannt-gute Version einfrieren können — aber es ist die häufigste Ursache für "warum verhält sich mein Plugin anders als die Docs sagen?" beim Upgrade.

:::tip Lies codex plugin list bevor du Verhalten debuggst codex plugin list zeigt installierte Plugins mit der Quell-Ebene an, aus der jedes aufgelöst wurde. Wenn ein Plugin etwas Überraschendes tut, ist das der erste Befehl — die Version, die du benutzt, ist eventuell nicht die, die du glaubst zu benutzen. :::

Kataloge konfigurieren — die minimale config.toml​

Marketplace-Endpunkte und Auto-Update-Verhalten werden in der config.toml von Codex gesetzt. Der v0.147.0-Default hält auto_update = false, was für Reproduzierbarkeit die richtige Wahl ist, aber bedeutet, dass du Updates bewusst laufen lassen musst.

# ~/.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

Das Katalog-Eintragslimit wurde in v0.147.0 von 512 auf 2.048 angehoben — eine kleine Zahl, die wichtig ist, wenn du Codex auf ein großes internes Registry zeigst. Unter 512 wurden Plugins jenseits der Grenze still aus den Suchergebnissen abgeschnitten; Enterprise-Teams sind darauf oft genug gestoßen, dass OpenAI die Decke angehoben hat.

Mit Plugins arbeiten — die Alltagskommandos​

Den gemergten Katalog in einem interaktiven Picker durchsuchen

/plugins

Alle vier Ebenen auf einmal durchsuchen

codex plugin marketplace search "terraform"

Das nach Priorität höchste Match per Name installieren

codex plugin install terraform-drift

Sehen, was installiert ist UND aus welcher Ebene es kam

codex plugin list

Jedes installierte Plugin aktualisieren (opt-in — auto_update ist standardmäßig aus)

codex plugin update

Drei Sicherheitshärtungen im Plugin-Install​

Der Plugin-Install-Pfad in v0.147.0 hat still drei Dinge verschärft — alle wert zu wissen, weil sie ändern, was "Install funktioniert" bedeutet.

Guided walkthrough1 of 3
  1. Wenn ein Plugin-Package einen Symlink enthält, überspringt Codex den Symlink, anstatt ihm zu folgen. Das blockiert eine ganze Klasse von Path-Traversal-Angriffen — ein bösartiges Plugin kann `plugin/config` nicht mehr auf `/etc/passwd` linken. Der Trade-off: legitime Packages, die Symlinks für geteilte Assets nutzten, müssen sie inline einbetten.

--approve-for-me: was es tatsächlich tut (und nicht tut)​

Der Name liest sich wie "jede Anfrage automatisch genehmigen". Das tut das Flag nicht. --approve-for-me leitet Freigabeanfragen durch einen automatischen Review-Pass, der jede Anfrage gegen deinen aktiven Sandbox-Modus und deine Approval-Policy-Konfiguration abwägt. Wenn die Policy "ja, das ist innerhalb der Whitelist" sagt, läuft die Anfrage ohne Prompt weiter. Wenn die Policy "nein oder unklar" sagt, wird die Anfrage abgelehnt — du wirst nur nicht mitten im Lauf gefragt.

Zwei Dinge, die weiterhin gelten:

  • Die OS-Level-Sandbox wird weiterhin durchgesetzt. Unter Linux via Bubblewrap; unter macOS via die Plattform-Sandbox. --approve-for-me kann die Sandbox nicht verlassen; es kann nur entscheiden, ob Prompts innerhalb davon automatisch beantwortet werden.
  • Cyber-fähige Modelle bekommen automatisch die sichereren Defaults aus v0.146.1. Netzwerkzugriff, Credential-Reads und Prozessverwaltung bleiben verweigert, sofern nicht explizit gewhitelistet, egal was --approve-for-me sagt.

Das richtige mentale Modell: --approve-for-me macht deine Policy-Datei zum Menschen. Wenn deine Policy locker ist, ist dieses Flag gefährlich; wenn deine Policy eng ist, ist dieses Flag das fehlende Stück für unattended Runs.

Interaktiver Lauf — Policy entscheidet über Freigaben, Sandbox bleibt an

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

Exec (nicht-interaktiver) Lauf mit strukturiertem Output-Kontrakt

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

Eine minimale Approval-Policy, die sinnvoll zum Flag passt:

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

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

Alles, was nicht auf dieser Allow-Liste steht, wird verweigert — auch durch --approve-for-me.

Der stille Breaking Change: --full-auto ist entfernt​

Wenn du CI oder Makefiles hast, die codex exec --full-auto aufrufen, brechen sie auf v0.147.0. Das Flag ist weg. Der Ersatz ist explizit:

# Vor v0.147.0 (jetzt kaputt)
codex exec --full-auto "run tests"

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

Die beiden sind nicht identisch: --full-auto kombinierte eine Sandbox-Wahl und eine Approval-Policy-Wahl. Die neue Form verlangt, dass du die Sandbox explizit angibst, und wenn du die "frag mich nicht"-Hälfte zurück willst, fügst du --approve-for-me hinzu. Das lohnt zu greppen, bevor du einen gemeinsamen Runner upgradest.

MCP 2026-07-28 in Codex — drei Dinge, die du tatsächlich bekommst​

Codex hat die neue MCP-Spec in v0.147.0 zum opt-in gemacht. Schalte sie ein, wenn ein Server, auf den du dich verlässt, migriert ist; lass sie sonst aus. Drei konkrete Gewinne, wenn du den Schalter umlegst:

  • Paginierte Discovery. Server, die 200+ Tools freigeben, zwingen nicht mehr eine riesige One-Shot-Liste; der Client pagiert sich durch. Die Latenz zum ersten Tool wird viel geringer.
  • Multi-Round-Requests. Eine einzelne logische Operation kann mehrere Client↔Server-Runden umspannen — denk an ein interaktives Formular, ein Two-Step-Confirm oder einen Resource-Read, der einen Follow-up-Token zurückgibt. Vor 2026-07-28 musste das in einen Payload gepresst werden.
  • Nicht-blockierender Server-Start. Codex blockiert seinen eigenen Boot nicht mehr auf langsamen MCP-Servern. Ein Server, der 4 Sekunden zum Aufwärmen braucht, hat das ganze CLI eingefroren; jetzt startet Codex, und der Server wird als bereit markiert, wenn er es ist.

Wie sich das auf Claude Code mappen lässt, in einer Tabelle​

Wenn dein Instinkt Claude ist, ist das die Übersetzungstabelle für dieselben Konzepte.

KonzeptCodex CLI (v0.147.0)Claude Code
Portable Instruction-EinheitSkill (SKILL.md-Ordner)Skill (SKILL.md-Ordner) — derselbe offene Standard
Packaging / DistributionAgent Plugin (bündelt Skills, MCPs, Config)Plugin-Marketplace + Skill-Install
Discovery-ScopeVierstufiger Katalog (lokal → persönlich → Workspace → remote)Projekt + User + Marketplace
Auto-Approve innerhalb Sandbox--approve-for-me + approval_policyPermissions in ~/.claude/settings.json
Sandbox-DurchsetzungBubblewrap (Linux) / macOS-SandboxSandbox mit Credential-Masking
Langlaufende MCP-ServerNicht-blockierender Start (MCP 2026-07-28)Blockierender Start, sofern du nicht opt-in machst
"Instruktionen im Repo".codex/plugins/, AGENTS.md.claude/, CLAUDE.md

Der größte praktische Unterschied: Codex' vierstufiger Katalog mit In-Repo-.codex/plugins/-Shadowing ist aggressiver als der Default von Claude Code. Das ist ein Feature — ein Repo kann eine Plugin-Version pinnen und sichergehen, dass alle sie ausführen — aber es bedeutet, dass "Plugin geupgradet und nichts hat sich geändert" oft "dein Repo hat eine ältere Kopie gepinnt" heißt.

Eine Migrations-Checkliste für Teams, die schon auf Codex sind​

Guided walkthrough1 of 6
  1. Das ist die häufigste Ursache für grüne CIs, die rot werden, nachdem `codex --version` springt.

Wann Codex-Plugins Claude-Subagents schlagen — und wann nicht​

Codex-Plugins sind am stärksten, wenn die Wiederverwendungseinheit ein Workflow-Package ist — ein Review-Flow, eine Deploy-Sequenz, ein Terraform-Drift-Sweep — das du als ein Artefakt über ein ganzes Team ausliefern willst, mit Versionierung und einem Marketplace dahinter. Der vierstufige Katalog ist echt nützlich in Organisationen, die "das Reviewer-Plugin, das das Plattform-Team ausliefert, es sei denn mein Repo überschreibt es" brauchen.

Claude Codes Subagent-plus-Skill-Modell ist stärker, wenn die Wiederverwendungseinheit eine Rolle ist ("code-reviewer", "debugger"), die frei innerhalb einer einzelnen interaktiven Session komponiert, und wenn du dieselbe Datei in ChatGPT, Cursor, Gemini CLI und Codex laufen lassen willst, ohne neu zu packagen. Skills bleiben das portablere Primitiv; Plugins sind die mächtigere Distributionsschicht.

Die praktische Antwort für die meisten Teams im August 2026 ist beides: halte Skills als File-Level-Primitiv, damit sie über Agents wandern, und packe sie in ein Codex Agent Plugin, wenn du den Marketplace, die Katalog-Föderation und das Pinning brauchst.

Check yourself

0/4
  1. Zwei Kataloge enthalten ein Plugin namens `terraform-drift`: eines committet in `.codex/plugins/` im Repo, eines auf `marketplace.openai.com`. Welches benutzt Codex?
  2. Du führst `codex exec --approve-for-me --sandbox workspace-write "install curl and hit a random URL"` aus. Deine Approval-Policy erlaubt nur `api.github.com`. Was passiert?
  3. Dein CI-Makefile ruft immer noch `codex exec --full-auto "run tests"` auf. Nach dem Upgrade auf v0.147.0 schlägt der Job fehl. Was ist der minimale Fix, der die alte Intention erhält?
  4. Welches MCP 2026-07-28-Feature behebt am direktesten 'Codex braucht 4 Sekunden zum Starten, weil ein MCP-Server langsam aufwärmt'?

Quellen & weiterführende Lektüre​