Das Plugin-Update vom 25. März 2026 – was sich für Entwickler ändert und wie es sich zu Claude Code verhält
SerieOpenAI & ChatGPT
Teil 4 von 4
OpenAI hat Codex am 25. März 2026 um ein Plugin-System erweitert. Seit dem 27. März 2026 ist es in der Codex-App live. Das ist kein kleines Feature-Update.
Bisher musste man Codex bei jedem Projekt neu erklären, wie es funktioniert – Namenskonventionen, Frameworks, Teamregeln. Mit dem Plugin-System wird dieses Wissen einmal definiert und dauerhaft nutzbar. Aus dem einmaligen Helfer wird ein wiederverwendbares Team-Werkzeug. Statt jedes Mal neu zu erklären, wie dein Projekt aufgebaut ist, kapselst du dieses Wissen einmal – und nutzt es dauerhaft.
Was das konkret bedeutet – und wie es sich zu Anthropics Claude Code verhält – das schauen wir uns hier durch.
Was Codex bisher konnte
OpenAI Codex ist kein Chatbot. Er ist ein Coding-Agent: ein KI-System, das Code schreibt, Dateien anlegt, Terminal-Befehle ausführt und eigenständig auf Repositories arbeitet. Wer ChatGPT kennt, kennt damit noch nicht Codex – der Unterschied liegt im Autonomiegrad. Codex agiert in einer Sandbox, bekommt eine Aufgabe und arbeitet sie ab. Er liest Kontext, trifft Entscheidungen, schreibt Code, führt Tests aus.
In den letzten Monaten hat OpenAI Codex kontinuierlich ausgebaut: bessere IDE-Integration, stabilere CLI, stärkere Modelle im Hintergrund. Das Plugin-System ist der bisher größte Architektur-Schritt.
Das Plugin-System: Was genau hinzukommt
Ein Plugin für Codex ist kein einzelnes Feature – es ist ein Container für drei unterschiedliche Erweiterungstypen:
Skills sind wiederverwendbare Workflows. Ein Skill bündelt Anweisungen, Ressourcen und Skripte zu einem standardisierten Paket. Der Standard ist offen, was bedeutet: Skills lassen sich prinzipiell zwischen Tools austauschen, die denselben Standard implementieren.
Apps und Konnektoren verbinden Codex mit externen Diensten – GitHub, Slack, Jira, Notion. Damit kann Codex nicht nur Code schreiben, sondern direkt auf Tickets, Pull Requests und Notifications reagieren.
MCP-Server integrieren externe Tools und Kontext über das Model Context Protocol. Wer MCP kennt, weiß: das ist kein OpenAI-Standard, sondern ein offenes Protokoll, das ursprünglich von Anthropic entwickelt wurde und inzwischen von mehreren Anbietern unterstützt wird.
Die drei Typen lassen sich kombinieren. Ein Plugin kann gleichzeitig Skills, App-Konnektoren und MCP-Server enthalten.
In 30 Sekunden: Was ändert sich für dich?
Bevor es in die Details geht – die praktische Zusammenfassung:
- Weniger Prompt-Wiederholung: Projektregeln und Konventionen einmal als Skill definieren, nicht bei jedem Task neu erklären
- Reproduzierbare Ergebnisse: Gleicher Skill, gleiche Qualität – unabhängig davon, wer im Team die Aufgabe startet
- Integration in echte Workflows: Tickets holen, Code schreiben, PR erstellen – alles in einem Durchgang
- Wissen wird teamweit nutzbar: Skills lassen sich teilen, versionieren und zwischen Projekten wiederverwenden
Das ist der eigentliche Shift: Codex hört auf, ein individuelles Werkzeug zu sein. Es wird zur gemeinsamen Infrastruktur.
Wie sieht ein Plugin aus?
Ein Codex-Plugin hat eine einfache Grundstruktur:
{
"skills": [...],
"connectors": [...],
"mcpServers": [...]
}Alle drei Typen sind optional – ein reines Skills-Plugin braucht keine Konnektoren, und umgekehrt. Das macht den Einstieg niedrigschwellig: Man beginnt mit einem einzigen Skill für einen konkreten Workflow und erweitert von dort.
Skills im Detail
Ein Skill ist das Kernkonzept des neuen Systems. Was er konkret enthält:
- Anweisungen: Wie soll Codex vorgehen, wenn der Skill aufgerufen wird?
- Ressourcen: Welche Dateien, Templates oder Konfigurationen braucht der Skill?
- Skripte: Welche Shell- oder Python-Skripte gehören zur Ausführung?
Skills sind in CLI, IDE-Extensions und der Codex-App verfügbar. Sie standardisieren keine einzelne Aufgabe, sondern einen ganzen Workflow: Komponente erstellen, Migration schreiben, API-Endpunkt anlegen – mit allen Projektregeln und Konventionen, die das Team definiert hat.
Ein konkretes Beispiel aus der Praxis – ein Skill für API-Endpunkte:
skill: create-api-endpoint
steps:
- generate controller
- create route
- add validation
- write tests
rules:
naming: kebab-case
framework: expressDas ersetzt 5–10 Minuten manuelles Setup pro Endpunkt. Wer täglich mehrere Endpunkte anlegt, merkt das schnell.
Ein weiteres Beispiel: Ein Team hat eigene Namenskonventionen für Datenbankmigrationen, nutzt ein internes ORM und will immer bestimmte Teststrukturen miterzeugen. Ohne Skill erklärt jeder das dem Agenten neu. Mit einem Skill ist das einmal definiert und steht jedem Entwickler im Team sofort zur Verfügung.
MCP: Codex trifft auf das Model Context Protocol
MCP ist im Grunde eine standardisierte API-Schicht für KI-Agenten. Es legt fest, wie ein Agent Kontext abfragt, Aktionen ausführt und Ergebnisse zurückbekommt – einheitlich, unabhängig vom Anbieter. Was das Protokoll grundlegend macht und wie ein MCP-Server aufgebaut ist, haben wir in MCP Server verstehen: Die Brücke zwischen KI und deinen Daten ausführlich beschrieben.
In der Praxis bedeutet das, dass ein MCP-Server Dinge wie diese bereitstellen kann:
- Datenbank-Schema: Codex fragt direkt die aktuelle Struktur ab, statt auf veraltete Dokumentation angewiesen zu sein
- Deployment-Logs: Kubernetes-Logs oder CI-Ergebnisse abrufen und im Kontext des Tasks verarbeiten
- Interne Dokumentation: Confluence, Notion oder eigene Wikis durchsuchen, ohne den Kontext zu verlassen
Ein konkretes Praxisbeispiel, wie ein solcher MCP-Server im Unternehmenskontext aussieht – etwa für ein Vertriebsteam mit CRM-Zugang – zeigt der Artikel MCP in der Praxis: Ein Vertriebsteam bekommt seinen eigenen KI-Zugang zum CRM.
Wer bisher MCP-Server für andere Tools gebaut hat – etwa für Claude Code oder für eigene Automatisierungen – kann diese jetzt prinzipiell auch mit Codex nutzen. Das ist ein relevanter Schritt: MCP war bislang eng mit dem Anthropic-Ökosystem assoziiert. OpenAIs Entscheidung, MCP in Codex zu integrieren, macht das Protokoll de facto zum Standard für AI-Tool-Integration.
Wie verbindlich ist das Commitment? Bei MCP ist die Situation klarer: OpenAI adoptiert ein bestehendes, offen spezifiziertes Protokoll – das Governance liegt nicht bei OpenAI, sondern ist unabhängig. Wer MCP-Server baut, ist nicht von OpenAIs Roadmap abhängig.
Bei Skills sieht es anders aus: Der Standard ist „offen” im Sinne von dokumentiert und portierbar, aber OpenAI kontrolliert die Spezifikation. Es gibt keine unabhängige Governance, keinen offenen Prozess für Weiterentwicklung. Das bedeutet praktisch: Interoperabilität ist heute möglich, bleibt aber davon abhängig, dass OpenAI den Standard stabil hält und andere Tools ihn implementieren. Stand jetzt ist beides nicht garantiert.
Codex Plugins vs. Claude Code
Beide Systeme nähern sich dem gleichen Problem an: Wie macht man einen Coding-Agenten für spezifische Teams, Projekte und Workflows anpassbar? Die Konzepte sind ähnlich, die Umsetzung unterscheidet sich in Details.
| Funktion | OpenAI Codex Plugins | Claude Code |
|---|---|---|
| Wiederverwendbare Workflows | Skills (Anweisungen + Ressourcen + Skripte) | /-Slash Commands, CLAUDE.md |
| MCP-Integration | Ja, nativ via Plugin | Ja, nativ via .mcp.json |
| Externe Dienste | Apps/Konnektoren im Plugin | MCP-Server, Hooks |
| Offener Standard | Ja, bei Skills | Teilweise (MCP offen, Commands proprietär) |
| IDE-Integration | CLI, IDE-Extensions, App | CLI, IDE-Extension (VS Code, JetBrains) |
| Team-Sharing | Via Plugin-Paket | Via Repository (CLAUDE.md, .claude/) |
| Berechtigungsmodell | Sandbox-basiert | Explizite Permissions pro Aktion |
Was ähnlich ist: Beide Systeme trennen Konfiguration von Nutzung. Skills bzw. CLAUDE.md legen fest, wie der Agent arbeitet – der Entwickler gibt nur die Aufgabe. Beide unterstützen MCP, beide sind in gängigen IDEs verfügbar.
Was sich unterscheidet: Claude Code ist tiefer in das Berechtigungsmodell integriert – jede Aktion (Dateischreiben, Netzwerkzugriff, Terminalbefehl) erfordert explizite Freigabe. Codex arbeitet stärker in einer Sandbox, die vorab konfiguriert wird. Das ist keine Wertung – es sind zwei unterschiedliche Philosophien für dasselbe Problem.
Kurzentscheidung:
- Codex → wenn du schnell starten willst und starke Integration mit OpenAI-Diensten brauchst
- Claude Code → wenn du maximale Kontrolle über einzelne Aktionen willst und tief in IDE-Workflows arbeitest
Risiken und Grenzen
Das Plugin-System bringt echte Hebel – aber auch neue Risiken, die man kennen sollte:
- Skills können falsche Patterns automatisieren: Ein schlecht definierter Skill wiederholt Fehler systematisch, nicht nur einmalig. Qualitätssicherung beim Erstellen ist wichtiger als beim manuellen Prompting.
- MCP-Server = potenzieller Datenzugriff: Wer einen MCP-Server einbindet, der auf Datenbankschemas oder interne Logs zugreift, sollte genau wissen, welche Daten damit im Agenten-Kontext landen.
- Konnektoren zu produktiven Systemen: Ein Konnektor zu Jira oder GitHub kann Tickets kommentieren, PRs öffnen und Labels setzen. In einem Workflow ohne menschliche Review-Schleife kann das schnell unkontrolliert werden.
Die Empfehlung: Mit Read-Only-Berechtigungen starten, bevor man schreibenden Zugriff auf produktive Systeme einrichtet.
Was das für Entwickler bedeutet
Portabilität wird konkreter
Skills mit offenem Standard sind ein Signal, das über Codex hinausgeht. Wenn Workflows in einem standardisierten Format vorliegen, lassen sie sich zwischen Tools übertragen. Das ist aktuell noch Theorie – aber die Richtung stimmt. Wer heute in Skills investiert, baut auf einer Basis, die nicht an einen einzigen Anbieter gebunden ist.
Von Werkzeug zu Plattform
Das Plugin-System verschiebt Codex von einem Werkzeug zu einer Plattform. Vorher: Codex führt Tasks aus. Nachher: Codex orchestriert Systeme.
Ein konkretes Beispiel dafür, wo die Reise hingeht:
Statt „schreib mir Code für Ticket 123” wird es: „Nimm Ticket 123, implementiere es, erstelle einen PR, schreibe Tests und kommentiere im Jira.”
Das ist der eigentliche Shift. Codex hört auf, auf einzelne Prompts zu reagieren, und beginnt, als Teil eines größeren Workflows zu agieren. Für Freelancer und kleine Teams bedeutet das: Der Einstiegsaufwand steigt leicht (Plugin konfigurieren, Skills definieren), aber der Ertrag wächst mit jedem Projekt, das dieselbe Konfiguration nutzt.
Wann lohnt sich der Aufwand?
Für wen konkret?
Drei Szenarien, wo das Plugin-System sofort Mehrwert bringt:
Startup-Team: Skill für Feature-Entwicklung – Komponente erstellen, Tests schreiben, PR öffnen, Ticket auf „In Review” setzen. Einmal definiert, jedes Mal gleich.
Agentur: Skill für Landingpage-Erstellung mit SEO-Struktur – Heading-Hierarchie, Meta-Tags, Schema.org. Jedes Kundenprojekt startet auf demselben Niveau.
Freelancer: Skill für wiederkehrende Kundenprojekte – CRUD-Endpoints, Auth-Setup, Deployment-Vorbereitung. Was früher 30 Minuten Boilerplate war, ist jetzt ein Befehl.
Was jetzt sinnvoll ist
Einordnung
Plugin-Systeme sind der nächste natürliche Entwicklungsschritt für Coding-Agenten. Einzelne Fähigkeiten waren der Anfang – jetzt geht es darum, wie diese Fähigkeiten konfigurierbar, teilbar und interoperabel werden.
OpenAI und Anthropic verfolgen dabei ähnliche Ansätze mit leicht unterschiedlichen Schwerpunkten. Codex setzt auf ein explizites Plugin-Format und offene Standards bei Skills. Claude Code setzt auf ein dateibasiertes Konfigurationsmodell und granulare Berechtigungen. Was besser passt, hängt vom Workflow ab: Codex hat stärkere Out-of-the-Box-Integration mit OpenAI-Diensten, Claude Code ist tiefer in das Berechtigungsmodell und die IDE-Steuerung integriert.
Entscheidend ist MCP: Beide Systeme unterstützen es, und je mehr Tools auf MCP setzen, desto weniger hängt die Wahl des Agenten davon ab, welche Integrationen er mitbringt. Der eigene MCP-Server funktioniert mit beiden.
Was sich gerade vollzieht, lässt sich in einem Satz zusammenfassen: Wir bewegen uns von Prompting zu Systemdesign. Skills sind das neue Framework-Wissen, MCP das neue API-Ökosystem, Plugins die neue Distributionsebene. Wer das versteht, ist früh dabei.