Ich habe OpenAIs neue Codex Plugins getestet — hier ist die Wahrheit

Die Slack-Benachrichtigung eines befreundeten Entwicklers erreichte mich um 23 Uhr an einem Mittwoch: "Codex hat gerade Plugins veröffentlicht. Es gibt über 20 Stück. Du musst dir das Build iOS Apps Plugin ansehen."

Ich war mitten in einer Claude Code-Session, drei Agents tief in einem parallelen Workflow, und mein erster Instinkt war, es zu ignorieren. Noch ein Feature-Release. Noch ein Ökosystem-Schachzug. Ich würde mich am Wochenende damit befassen.

Dann öffnete ich die Codex-App, tippte /plugins und sah, was OpenAI tatsächlich gebaut hatte. Das war kein Marktplatz, der an die Seite eines Coding-Tools geschraubt wurde. Es war eine Architektur — Skills, Konnektoren für Drittanbieter-Apps und MCP Server, gebündelt in installierbare Pakete, die grundlegend verändern, was Codex von Haus aus kann. Ich schloss meine Claude Code-Session. Das brauchte meine volle Aufmerksamkeit.

Ich habe die letzten zwei Tage damit verbracht, jedes Plugin zu installieren, das ich in die Finger bekommen konnte, das Build iOS Apps Plugin gegen ein echtes Projekt zu stressen und die Manifest-Dateien auseinanderzunehmen, um zu verstehen, wie das System unter der Haube wirklich funktioniert. Was ich fand, ist ein Plugin-System, das gleichzeitig leistungsfähiger und frustrierender ist, als ich erwartet hatte.

Hier ist alles — die Architektur, die es interessant macht, die praktische Erfahrung, die die Lücken aufzeigt, und ob dies das Wettbewerbsbild für AI-Coding-Tools im Jahr 2026 verändert.

Warum dieser Plugin-Launch gerade jetzt wichtig ist

OpenAI hat Codex Plugins am 26. März 2026 mit mehr als 20 Integrationen veröffentlicht, die über die Codex-App, CLI und VS Code-Erweiterung verfügbar sind. Dieses Timing ist kein Zufall. Der Markt für AI-Coding-Tools zersplittert — Claude Code hat seine Agent-Teams und sein Skills-System, Cursor hat seine Composer-Workflows, und jede große IDE liefert AI-Features. OpenAI brauchte einen Weg, Codex unverzichtbar zu machen.

Plugins sind ihre Antwort. Und es ist eine clevere, denn das eigentliche Problem mit jedem AI-Coding-Assistenten ist nicht die AI selbst — es ist die Integrationslücke. Man kann das leistungsfähigste Modell der Welt haben, aber wenn es nicht mit dem Projektmanagement-Tool kommunizieren, die Design-Dateien nicht lesen oder das Build-System nicht auslösen kann, kopiert und fügt man immer noch zwischen Fenstern ein, als wäre es 2023.

Ich lebe seit Monaten mit genau diesem Schmerz. Mein Workflow umfasst Slack für Teamkommunikation, GitHub für Versionskontrolle, Figma für Design-Referenzen und Xcode für iOS-Builds. Vor Codex Plugins erforderte die Verbindung all dessen entweder benutzerdefinierte MCP Server-Konfigurationen oder viel manuelles Context-Feeding. Das Versprechen von Plugins ist, dass jemand anderes diese Verdrahtung bereits erledigt hat — man installiert und legt los.

Die Frage ist, ob dieses Versprechen in der Praxis hält. Spoiler: An manchen Stellen ja und an anderen absolut nicht. Aber die zugrundeliegende Architektur ist solide genug, dass sich die rauen Kanten behebbar anfühlen, nicht fundamental.

Bevor ich die spezifischen Plugins durchgehe, die ich getestet habe, muss man verstehen, wie das Drei-Schichten-System tatsächlich funktioniert — denn diese Architektur bestimmt alles darüber, was Plugins können und was nicht.

Die Drei-Schichten-Architektur: Skills, Apps und MCP Server

Jedes Codex Plugin ist ein Paket, das bis zu drei Arten von Komponenten enthält, und das Verständnis der Unterschiede zwischen ihnen hat mir beim Testen stundenlange Verwirrung erspart. Die meiste Berichterstattung über diesen Launch behandelt "Plugins" als monolithisches Konzept. Das sind sie nicht. Die drei Schichten dienen völlig unterschiedlichen Zwecken.

Skills: die Gehirnschicht

Skills sind wiederverwendbare Anweisungen, die Codex sagen, wie bestimmte Arten von Arbeit anzugehen sind. Sie können so einfach wie ein Text-Prompt sein — "Verwende beim Scaffolding einer React-Komponente immer TypeScript Interfaces statt Type Aliases" — oder so komplex wie ein mehrstufiges Build-Script, das Kompilierung, Tests und Deployment verwaltet.

Was Skills anders macht als einfach Anweisungen in den System-Prompt zu kopieren, ist Persistenz und Teilbarkeit. Ein Skill lebt im Plugin-Paket. Jeder, der dieses Plugin installiert, bekommt denselben Skill. Und Codex lädt relevante Skills automatisch basierend auf der aktuellen Aufgabe, anstatt zu verlangen, dass man sich merkt, welche Anweisungen zu welcher Aufgabe gehören.

Ich testete dies mit den Skills des Build iOS Apps Plugins, darunter ein iOS-Debugger-Skill und ein Projekt-Scaffolding-Skill. Der Debugger-Skill sagt nicht einfach "hilf mir, iOS-Apps zu debuggen" — er enthält spezifisches Wissen über die Xcode Build MCP-Integration, häufige SwiftUI-Layout-Probleme und wie man Xcodes notorisch kryptische Fehlermeldungen interpretiert. Als ich Codex bat, ein Layout-Rendering-Problem in einer SwiftUI-Preview zu debuggen, rief es automatisch den Debugger-Skill auf und arbeitete den Diagnoseprozess in einer sinnvollen Reihenfolge ab.

Die Einschränkung: Skills sind nur so gut wie die Anweisungen, die sie enthalten. Ein schlecht geschriebener Skill ist schlimmer als gar kein Skill, weil Codex schlechte Anweisungen selbstbewusst befolgt. Es gibt keine Validierungsschicht, die prüft, ob der Rat eines Skills tatsächlich korrekt ist.

Apps: die Händeschicht

Apps sind Konnektoren für Drittanbieter-Dienste — die Teile, die Codex erlauben, mit Tools wie Slack, GitHub, Notion, Gmail, Google Drive, Box, Figma, Linear, Canva und anderen zu interagieren. Wenn man ein Plugin installiert, das einen App-Konnektor enthält, gibt man Codex die Fähigkeit, Informationen aus diesem Dienst zu lesen und Aktionen darin auszuführen.

Hier kommt Authentifizierung ins Spiel. Jeder App-Konnektor erfordert seinen eigenen Auth-Flow, und während meiner Tests reichte dies von nahtlos (GitHubs OAuth dauerte etwa zehn Sekunden) bis nervig (ein Konnektor erforderte, dass ich manuell einen API-Token generierte, einfügte und das Plugin neu startete). Die Auth-Erfahrung ist inkonsistent, und ich vermute, sie wird erheblich variieren, je nachdem welchen Drittanbieter-Dienst man verbindet.

Einmal authentifiziert, funktionieren die App-Konnektoren gut. Ich verband das Slack Plugin und bat Codex, einen Channel zusammenzufassen, in dem mein Team ein Deployment-Problem diskutiert hatte. Es zog die letzten 50 Nachrichten, identifizierte die relevante technische Diskussion und gab mir eine Zusammenfassung, die tatsächlich die Nuancen einfing — nicht nur "Leute sprachen über Deployments", sondern "das Team identifizierte eine Race Condition im Queue Worker, die bei mehr als 200 gleichzeitigen Verbindungen auftritt." Dieses Maß an kontextuellem Verständnis ist wirklich nützlich.

Der Figma-Konnektor ist ein weiterer Höhepunkt. Direkt aus einer Coding-Session heraus auf eine Design-Datei verweisen zu können — "übernimm die Abstände aus diesem Figma-Frame" — eliminiert einen der nervigsten Kontextwechsel in der Frontend-Entwicklung.

MCP Server: das Nervensystem

Model Context Protocol Server sind die Middleware-Schicht, die Codex mit externen Build-Tools, Datenbanken, Monitoring-Systemen und allem anderen verbindet, was eine persistente, bidirektionale Verbindung benötigt. Wenn Skills das Gehirn sind und Apps die Hände, dann sind MCP Server das Nervensystem, das unter allem verläuft.

Der wichtigste MCP Server im aktuellen Plugin-Ökosystem ist Xcode Build MCP, der mit dem Build iOS Apps Plugin ausgeliefert wird. Dieser Server verwaltet Build-bezogene Aufgaben — Targets auflisten, Kompilierung auslösen, Build-Output erfassen und die App im Simulator starten. Er verwandelt Codex von einem Code-Vorschlagstool in etwas, das eher einem Build-System-Operator ähnelt.

Ich verfolge den MCP-Standard aufmerksam, seit Anthropic die Spezifikation veröffentlicht hat, und zu sehen, dass OpenAI ihn für Codex Plugins übernimmt, ist bedeutsam. Es bedeutet, dass Plugins dieselbe MCP Server-Infrastruktur nutzen können, die Claude Code, Cursor und andere Tools aufbauen. Ein gut gebauter MCP Server funktioniert über das gesamte Ökosystem, nicht nur innerhalb des Tools eines Anbieters.

Die praktische Implikation: Wenn man bereits MCP Server für ein anderes Coding-Tool eingerichtet hat, lässt sich ein Teil dieser Konfiguration möglicherweise auf Codex Plugins übertragen. Ich testete dies mit einem benutzerdefinierten MCP Server, den ich für einen Datenbank-Monitoring-Workflow gebaut hatte, und mit einigen Manifest-Anpassungen funktionierte er innerhalb einer Codex Plugin-Struktur. Diese Portabilität ist wichtig.

Plugins installieren und verwalten: Wie der Prozess tatsächlich aussieht

Der Installationsablauf hat zwei Wege, die verschiedene Zielgruppen bedienen. Zu verstehen, welchen Weg man nutzen sollte, bewahrte mich vor einem frustrierenden Fehlstart.

Weg 1: das Plugin-Verzeichnis

Tippt man /plugins in der Codex-Oberfläche, erhält man ein durchsuchbares Verzeichnis verfügbarer Plugins. Jeder Eintrag zeigt den Plugin-Namen, eine Beschreibung, welche Komponenten enthalten sind (Skills, Apps, MCP Server) und einen Installationsbutton. Auf Installieren klicken, eventuelle Authentifizierungsanforderungen abschließen, und das Plugin ist sofort aktiv.

Das Verzeichnis umfasst derzeit Integrationen mit:

• Kommunikation: Slack (Channels zusammenfassen, Antworten entwerfen, Updates posten)
• Design: Figma (Designs referenzieren, Komponentenspezifikationen abrufen, Abstände prüfen)
• Projektmanagement: Linear (Issues verfolgen, Status aktualisieren, Tickets im Code referenzieren)
• Dokumentation: Notion (Referenzdokumente abrufen, Wikis aktualisieren, Wissensbasen durchsuchen)
• Speicher: Google Drive (Zugriff auf Dokumente, Tabellen und Präsentationen), Box (Dateiverwaltung)
• E-Mail: Gmail (E-Mails im Coding-Kontext lesen und verwalten)
• Code: GitHub (PR-Verwaltung, Issue-Tracking, Code-Suche), Sentry (Fehlerüberwachung), Hugging Face (Modellreferenzen)
• Design-Tools: Canva (Verwaltung von Design-Assets)
• Entwicklungsworkflows: Build iOS Apps, Build macOS Apps

Einmal installiert, ruft man ein Plugin mit dem @-Symbol auf — @slack summarize #deployments oder @figma show me the header component from the main design file. Diese Konvention ist von anderen Tools bekannt und funktioniert intuitiv.

Etwas fiel mir sofort auf: Für kein Plugin werden Versionsinformationen angezeigt. Man kann nicht erkennen, wann ein Plugin zuletzt aktualisiert wurde, was sich zwischen Versionen geändert hat oder ob man die neueste Version nutzt. Für ein System, das produktionsreif sein soll, ist das eine echte Lücke. Ich bin schon oft genug von veralteten Tool-Integrationen überrascht worden, um dies als ein erhebliches Risiko zu betrachten.

Weg 2: lokale Plugin-Builds

Für benutzerdefinierte Plugins — oder wenn man ein vorhandenes modifizieren möchte — arbeitet man mit einer Manifest-Datei und einem lokalen Skills-Verzeichnis. Das Manifest ist eine JSON-Datei, die deklariert, was das Plugin enthält:

{
  "name": "my-custom-plugin",
  "description": "Custom workflow for my iOS development process",
  "skills": [
    {
      "name": "swift-conventions",
      "type": "prompt",
      "content": "When writing Swift code for this project, always use async/await instead of completion handlers. Prefer struct over class unless reference semantics are required. Use SwiftUI previews for every view component."
    }
  ],
  "mcp_servers": [
    {
      "name": "xcode-build",
      "command": "npx",
      "args": ["xcode-build-mcp"]
    }
  ]
}

Der Manifest-basierte Ansatz ist leistungsfähig, weil man mehrere Skills in einem einzigen installierbaren Paket kombinieren kann. Ich habe bereits eine Sammlung von Coding-Konventionen, Build-Scripts und projektspezifischen Anweisungen über verschiedene Konfigurationsdateien verstreut. Sie in ein Plugin zu verpacken bedeutet, dass ich mein gesamtes Workflow-Setup mit einem einzigen Befehl auf einer neuen Maschine installieren kann — oder es mit einem Teammitglied teilen kann, das einem Projekt beitritt.

Die Installation für lokale Plugins besteht darin, Codex auf die Manifest-Datei zu verweisen. Es liest die Deklaration, richtet etwaige MCP Server ein, lädt die Skills und macht alles über dasselbe @-Aufrufmuster verfügbar.

Was bei beiden Wegen fehlt, ist ein ordentliches Abhängigkeitssystem. Wenn Plugin A eine bestimmte MCP Server-Version benötigt, die mit den Anforderungen von Plugin B kollidiert, muss man den Konflikt selbst lösen. Das hat mich bei den aktuellen 20+ Plugins noch nicht getroffen, aber mit wachsendem Ökosystem wird es zum Problem.

Das Build iOS Apps Plugin testen: Wo Theorie auf Praxis trifft

Das Build iOS Apps Plugin war dasjenige, das mich alles schließen und aufmerksam werden ließ, also unterzog ich es dem gründlichsten Test. Dieses Plugin bündelt mehrere Skills — darunter einen iOS-Debugger und einen Projekt-Scaffolder — mit dem Xcode Build MCP Server, um einen Workflow für das Erstellen nativer iOS-Anwendungen innerhalb von Codex zu schaffen.

Das Setup

Ich hatte eine bestehende macOS-App — ein Markdown-Präsentationstool, an dem ich gearbeitet hatte — und wollte testen, ob das Plugin sie auf iOS portieren konnte. Das ist eine echte Aufgabe, die ich wochenlang aufgeschoben hatte, weil die Verwaltung von Multi-Target Xcode-Projekten eine jener Arbeiten ist, die langweilig genug sind, um sie ständig auf den "nächsten Sprint" zu verschieben.

Ich erstellte einen neuen Git-Branch (ich habe auf die harte Tour gelernt, AI-Tooling niemals auf meinem Main-Branch arbeiten zu lassen), öffnete das Projekt in Codex, installierte das Build iOS Apps Plugin und bat es, ein iPhone-Target zu meiner bestehenden Markdown-Präsentator-App hinzuzufügen.

Was funktionierte

Das Scaffolding war wirklich beeindruckend. Das Plugin erstellte ein iOS-App-Target, richtete die Build-Konfiguration ein, etablierte geteilten Code zwischen den macOS- und iOS-Targets und generierte die initialen SwiftUI-Views — alles über die Xcode Build MCP-Integration. Ich berührte Xcode während des initialen Setups kein einziges Mal.

Der Build-Test-Zyklus ist der Bereich, in dem das Plugin seinen Wert bewies. Codex schrieb Code, löste einen Build über den MCP Server aus, erfasste die Build-Ausgabe, identifizierte Fehler und behob sie — alles in einem kontinuierlichen Zyklus. Apples xcodebuild-Tool kann Schemes auflisten und Build-, Test- und Archive-Aktionen vom Terminal aus ausführen, und der MCP Server nutzt dies, um Codex in einer agentischen Schleife zu halten, anstatt dass ich in die Xcode-GUI wechseln muss.

Ich sah zu, wie es vier aufeinanderfolgende Build-Fehler löste — einen fehlenden Import, einen Type-Mismatch, eine veraltete API-Nutzung und ein fehlendes Entitlement — ohne mein Eingreifen. Jedes Mal las es die Fehlerausgabe, identifizierte die Ursache, wendete einen Fix an und baute neu. Dieser Zyklus hätte mich fünfzehn Minuten Xcode-Gefummel gekostet. Codex erledigte es in etwa neunzig Sekunden.

Was nicht funktionierte

Hier muss ich ehrlich sein, denn die Demos lassen das glatter aussehen als die Realität.

Die iPhone-App, die das Plugin produzierte, war funktional im strengsten Sinne — sie kompilierte, startete im Simulator und zeigte Folien aus meinen Markdown-Dateien an. Aber die UI war rau. Schriftfarben waren nicht für die Displayeigenschaften des iPhones optimiert. Die Folienwiedergabe war fehlerhaft — Übergänge ruckelten, und gelegentlich wurde eine Folie mit falschen Dimensionen gerendert. Die Bedienelemente (Vor-/Zurück-Buttons, ein Fortschrittsindikator) waren für ein macOS-Fenster positioniert und wirkten auf einem Handybildschirm unpassend.

Einige dieser Probleme resultieren aus der fundamentalen Herausforderung, ein Desktop-App-Konzept auf Mobilgeräte zu portieren. Der Scaffolding-Skill des Plugins geht von einer bestimmten App-Architektur aus, und wenn die bestehende App diesen Annahmen nicht entspricht, passt sich der generierte Code schlecht an. Mein Markdown-Präsentator verwendet benutzerdefinierte Rendering-Logik, die der Scaffolder nicht vollständig berücksichtigt hat.

Der Debugger-Skill identifizierte einige dieser UI-Probleme, als ich darauf hinwies, konnte sie aber nicht alle autonom beheben. Das Schriftfarbenproblem erforderte das Verständnis der Beziehung zwischen den Appearance-Einstellungen der App und iOS' Hell-/Dunkelmodus-Handhabung — eine Nuance, die die Anweisungen des Skills nicht tiefgehend genug abdeckten.

Und die Rendering-Bugs bei der Folienwiedergabe? Die stellten sich als Core Animation-Timing-Problem heraus, spezifisch für die Art, wie ich Übergänge implementiert hatte. Der Debugger-Skill schlug generische Fixes vor (Animationsdauern anpassen, auf Main-Thread-Verletzungen prüfen), aber der tatsächliche Fix erforderte das Verständnis meiner spezifischen Implementierung. Verständlich — kein Skill kann jede Codebase vorhersehen.

Das Urteil zum Build iOS Apps Plugin

Das Plugin ist ein solider Ausgangspunkt, aber keine fertige Lösung. Es bewältigt die mühsame Setup-Arbeit — Target-Erstellung, Build-Konfiguration, geteilte Code-Struktur — besser als jedes Tool, das ich bisher verwendet habe. Der Build-Zyklus über Xcode Build MCP ist wirklich leistungsfähig und spart echte Zeit. Aber der generierte iOS-Code braucht erhebliche Verfeinerung, bevor er Produktionsqualität hat.

Ich würde ihn auf etwa 60-70% des Weges zu einer auslieferbaren App einschätzen. Die letzten 30-40% — der Feinschliff, die plattformspezifischen Optimierungen, die Edge Cases — erfordern immer noch menschliche Expertise. Es als "noch nicht produktionsreif" zu bezeichnen, ist akkurat, aber es als nutzlos zu bezeichnen, wäre zutiefst unfair. Es komprimierte, was ein zweitägiges Portierungsprojekt gewesen wäre, auf eine vierstündige Verfeinerungssession.

Ein eigenes Plugin bauen: der Teil, über den niemand spricht

Die meiste Berichterstattung über diesen Launch konzentriert sich auf die vorgebauten Plugins. Das verfehlt die interessantere Geschichte: die Möglichkeit, benutzerdefinierte Plugins zu erstellen, die bestehende Workflows in teilbare, installierbare Pakete verpacken.

Ich beschloss, ein Plugin zu bauen, das drei Dinge kombiniert, die ich ständig nutze: meine Swift-Coding-Konventionen, ein Build-and-Run-Script für meine Standard-Projektstruktur und eine MCP Server-Verbindung zur Inspektion des Datenbankzustands. Vor Plugins lebten diese in separaten Konfigurationsdateien und erforderten manuelle Einrichtung bei jedem neuen Projekt.

Schritt 1: Skills definieren

Man beginnt mit den Skills — den wiederverwendbaren Anweisungen, die das Plugin bereitstellt. Ich erstellte drei:

Einen Coding-Konventionen-Skill, der den Swift-Styleguide meines Teams codiert: Namenskonventionen, Architekturmuster (MVVM mit Coordinators), Testanforderungen (jede öffentliche Funktion bekommt einen Unit Test) und SwiftUI-spezifische Richtlinien (Preview Providers für jede View, Environment Objects statt Singletons).

Einen Build-Script-Skill, der die tatsächlichen Shell-Befehle zum Kompilieren, Testen und Ausführen der App enthält. Das ist kein Prompt — es ist ein Script, das Codex über den MCP Server ausführt. Es handhabt den kompletten Build-Lebenszyklus: Clean, Build, Tests ausführen, Coverage-Reports generieren und die App im Simulator mit spezifischen Gerätekonfigurationen starten.

Einen Debug-Workflow-Skill, der einen systematischen Ansatz für häufige Probleme definiert: zuerst Build-Logs prüfen, dann Console-Output, dann Memory Graph, dann Instruments-Traces. Diese Reihenfolge spiegelt wider, wie ich nach Jahren der iOS-Entwicklung tatsächlich Probleme debugge, und die Codierung als Skill bedeutet, dass Codex denselben Prozess befolgt.

Schritt 2: MCP Server anschließen

Die Manifest-Datei deklariert, welche MCP Server das Plugin benötigt. Für mein Plugin sind das der Xcode Build MCP (für Build-Operationen) und ein benutzerdefinierter SQLite MCP Server, den ich zur Inspektion des lokalen Datenbankzustands während der Entwicklung gebaut habe.

{
  "name": "ios-dev-workflow",
  "description": "Complete iOS development workflow with Swift conventions, build automation, and database inspection",
  "skills": [
    {"name": "swift-conventions", "file": "skills/swift-conventions.md"},
    {"name": "build-script", "file": "skills/build-script.sh", "type": "script"},
    {"name": "debug-workflow", "file": "skills/debug-workflow.md"}
  ],
  "mcp_servers": [
    {
      "name": "xcode-build",
      "command": "npx",
      "args": ["xcode-build-mcp"]
    },
    {
      "name": "sqlite-inspector",
      "command": "node",
      "args": ["./mcp-servers/sqlite-inspector/index.js"]
    }
  ]
}

Schritt 3: Testen und iterieren

Das Plugin lokal installieren, gegen ein echtes Projekt laufen lassen und beobachten, wo es bricht. Meine erste Version hatte einen Skill-Konflikt — der Coding-Konventionen-Skill sagte "verwende immer async/await", während das Build-Script mit Completion-Handler-Mustern geschrieben war. Codex befolgte beide Anweisungen und generierte verwirrten, hybriden Code. Die Behebung bedeutete sicherzustellen, dass alle Skills innerhalb eines Plugins intern konsistent sind.

Der Iterationszyklus für benutzerdefinierte Plugins ist schnell. Skill-Datei bearbeiten, Plugin neu installieren, testen. Kein Kompilierungsschritt, kein Build-Prozess. Es sind nur Konfigurationsdateien und Scripts.

Die Kraft der Komposition

Was mich an benutzerdefinierten Plugins wirklich begeistert, ist das Kompositionspotenzial. Ich kann meinen gesamten iOS-Entwicklungsworkflow in ein Plugin verpacken. Ein Kollege, der an Android arbeitet, kann seinen verpacken. Wir installieren gegenseitig unsere Plugins und erben sofort die Best Practices und Automatisierungen des anderen.

Das ist dieselbe Idee hinter Skills-Systemen in anderen Tools — ich habe darüber geschrieben, wie skills.sh mit Claude Code Agents funktioniert — aber Codex' Implementierung fügt die App-Konnektor- und MCP Server-Schichten hinzu, was Plugins schwergewichtiger aber leistungsfähiger macht.

Für Teams, die ihren Entwicklungsprozess standardisieren müssen, ist dies das eigentliche Wertversprechen. Nicht die vorgebaute Slack-Integration — die kann das Team in zehn Minuten einrichten. Der Wert liegt darin, das angesammelte Wissen des Teams in ein Paket zu codieren, das jedes neue Teammitglied am ersten Tag installieren kann.

Wenn Sie lieber jemanden hätten, der diese Art von benutzerdefiniertem Entwicklungsworkflow von Grund auf baut, übernehme ich AI-Tooling- und Automatisierungsaufträge. Was ich gebaut habe, finden Sie unter fiverr.com/s/EgxYmWD.

Wie sich Codex Plugins im Vergleich zur Konkurrenz schlagen

Ich kann Codex Plugins nicht isoliert bewerten, weil ich aktiv drei andere Plugin/Skill-Ökosysteme nutze. Der Vergleich ist wichtig, weil die Wahl des AI-Coding-Tools zunehmend davon abhängt, welches Ökosystem die benötigten Integrationen bietet.

Codex Plugins vs. Claude Code Skills

Das Skill-System von Claude Code ist ausgereifter für reine Coding-Workflows. Skills in Claude Code sind tief in das Agent-Modell integriert — sie können Sub-Agents spawnen, Kontext über lange Sessions verwalten und Claudes starke Schlussfolgerungsfähigkeit für komplexe Architekturentscheidungen nutzen. Ich verwende Claude Code Agent Teams für Multi-Datei-Refactoring-Aufgaben, und die Skill-basierte Koordination ist etwas, das Codex Plugins noch nicht erreichen.

Wo Codex Plugins gewinnen, ist die App-Konnektor-Schicht. Claude Code hat keine native Slack-, Figma- oder Linear-Integration im selben gebündelten Format. Man kann MCP Server für diese Dienste manuell einrichten, aber die Ein-Klick-Installationserfahrung von Codex Plugins ist deutlich reibungsloser für Teams, die Integration ohne Konfiguration wollen.

Codex Plugins vs. Cursor Composer

Cursors Ansatz ist anders — er konzentriert sich auf IDE-native Integration statt auf Plugin-Erweiterbarkeit. Cursor ist ausgezeichnet darin, den Codebase-Kontext zu verstehen und passenden Code zu generieren, hat aber keinen Plugin-Marktplatz oder Skill-Sharing-Mechanismus. Wenn die Anforderungen über Code-Generierung hinausgehen — Projektmanagement-Integration, Design-Datei-Referenzen, Build-Automatisierung — benötigt Cursor externe Tools.

Die Ökosystem-Wette

Die ehrliche Einschätzung: Das Plugin-Ökosystem keines einzigen Tools ist bisher vollständig. Ich nutze Codex für seine Slack- und Figma-Konnektoren, Claude Code für seine Agent-Architektur und Schlussfolgerungstiefe und Cursor für seine IDE-Integration. Auf ein Tool zu konsolidieren würde bedeuten, Fähigkeiten zu verlieren, die ich täglich nutze.

OpenAIs Wette ist, dass das Plugin-Ökosystem schnell genug wächst, um Codex zum einzigen Tool zu machen, das man nicht verlassen muss. Diese Wette hängt vollständig davon ab, ob Drittentwickler hochwertige Plugins bauen — und aktuell ist die Selbstveröffentlichung von Plugins noch nicht verfügbar. OpenAI hat die anfänglichen 20+ Plugins kuratiert, aber das Ökosystem muss sich öffnen, bevor es mit der Breite der für Claude Code verfügbaren MCP Server konkurrieren kann.

Die Lücken, die Sie kennen müssen

Ich war positiv über die Architektur und möchte das mit den realen Einschränkungen ausbalancieren, auf die ich gestoßen bin. Das sind keine kleinen Beschwerden — es sind Probleme, die bestimmen, ob Plugins zentral für den Workflow werden oder ein nettes Extra bleiben.

Keine Plugin-Versionierung. Das ist die größte Lücke. Wenn ein Plugin aktualisiert wird, gibt es keine Möglichkeit zu erfahren, was sich geändert hat, ob es den Workflow brechen könnte oder wie man auf eine vorherige Version zurückrollt. Für einzelne Entwickler, die experimentieren, ist das ärgerlich. Für Teams, die in Produktions-Workflows auf Plugins vertrauen, ist es ein echtes Risiko.

Inkonsistente Authentifizierung. Einige Plugins authentifizieren nahtlos über OAuth. Andere erfordern manuelle Token-Generierung und Einfügen. Mindestens ein Plugin, das ich testete, erforderte einen Neustart von Codex nach der Authentifizierung, um die neuen Credentials zu übernehmen. Das muss standardisiert werden.

Kein Abhängigkeitsmanagement. Plugins können keine Abhängigkeiten zu anderen Plugins oder bestimmten MCP Server-Versionen deklarieren. Wenn das Ökosystem wächst und Plugins beginnen, Infrastruktur zu teilen, wird das Konflikte verursachen.

Begrenzte Fehlermeldungen. Wenn ein Plugin fehlschlägt, sind die Fehlermeldungen oft generisch — "plugin execution failed" ohne Details darüber, welche Komponente (Skill, App oder MCP Server) tatsächlich versagt hat. Das Debuggen von Plugin-Problemen erfordert mehr Trial-and-Error als nötig.

Nur macOS für die Codex-App. Die vollständige Plugin-Erfahrung erfordert die Codex Desktop-App, die derzeit nur auf macOS mit Apple Silicon läuft. CLI und VS Code-Erweiterung unterstützen Plugins, aber die Erfahrung ist eingeschränkt — man verliert das visuelle Plugin-Verzeichnis und einige Authentifizierungsflows. Windows-Alpha-Tests haben begonnen, aber Linux-Unterstützung ist noch nicht in Sicht.

Was das für Ihren Workflow 2026 bedeutet

Das Codex Plugin-System wird das bestehende Tool-Setup nicht über Nacht ersetzen. So funktioniert die Einführung von Entwickler-Tools nicht. Aber es verändert die Entscheidungsmatrix für Teams, die AI-Coding-Assistenten evaluieren.

Wenn Sie Codex bereits nutzen und Ihr Workflow Slack, GitHub, Figma oder einen der anderen integrierten Dienste umfasst, installieren Sie die relevanten Plugins sofort. Die Zeitersparnis beim Kontextwechsel allein rechtfertigt die zehn Minuten Einrichtung.

Wenn Sie Codex mit Claude Code oder Cursor vergleichen, wird das Plugin-System ein bedeutsamer Differenzierungsfaktor — aber nur, wenn die spezifischen Integrationen, die Sie benötigen, verfügbar sind. Prüfen Sie das Plugin-Verzeichnis vor einer Entscheidung, nicht danach.

Wenn Sie ein Teamleiter sind, der über die Standardisierung auf ein AI-Coding-Tool nachdenkt, ist die Fähigkeit zur Erstellung benutzerdefinierter Plugins das Feature, das am sorgfältigsten evaluiert werden sollte. Die Möglichkeit, die Konventionen, Build-Prozesse und Integrationsmuster des Teams in ein installierbares Paket zu codieren, ist ein echter Produktivitätsmultiplikator. Es verwandelt Onboarding von "lies das Wiki und finde unser Setup heraus" in "installiere dieses Plugin und fang an zu coden."

Und wenn Sie ein Tool-Entwickler oder MCP Server-Entwickler sind, ist dies ein Marktsignal. OpenAI setzt auf denselben MCP-Standard, den Anthropic vorangetrieben hat. Für MCP zu bauen bedeutet, dass die Integration über das gesamte Ökosystem funktioniert, nicht nur innerhalb des geschlossenen Gartens eines Anbieters.

Das Plugin-System wurde vor drei Tagen gestartet. Einige meiner Beschwerden werden in Updates adressiert. Andere repräsentieren Architekturentscheidungen, die sich nicht schnell ändern werden. Aber das Fundament — Skills für Wissen, Apps für Integration, MCP Server für Infrastruktur — ist solide. Was in den nächsten sechs Monaten darauf aufgebaut wird, wird bestimmen, ob Codex Plugins essentiell oder nur interessant werden.

Ich plane, ein benutzerdefiniertes Plugin zu bauen, das meinen kompletten AI-Entwicklungsworkflow umfasst — Skills von Claude Code, MCP Server, die ich für Datenbank- und Monitoring-Tools gebaut habe, und App-Konnektoren für die Dienste, auf die mein Team angewiesen ist. Wenn es fertig ist, werde ich das Manifest teilen und den gesamten Build-Prozess durchgehen.

Für den Moment sind die zwanzig-plus Plugins, die zum Launch verfügbar sind, das Installieren und Testen wert. Beginnen Sie mit denen, die sich mit Diensten verbinden, die Sie bereits täglich nutzen. Das Slack Plugin allein hat mir bereits mehr Zeit gespart als der gesamte Testprozess gekostet hat.

Der Krieg um AI-Coding-Tools dreht sich nicht mehr darum, welches Modell den besten Code generiert. Es geht darum, welches Tool sich am nahtlosesten in die Art einfügt, wie man bereits arbeitet. Plugins sind OpenAIs stärkster Zug, diesen Krieg zu gewinnen — heute unvollkommen, aber architektonisch positioniert, um sehr schnell viel besser zu werden.

Häufig gestellte Fragen

Was sind OpenAI Codex Plugins?

Codex Plugins sind installierbare Pakete, die drei Arten von Komponenten bündeln — Skills (wiederverwendbare Anweisungen), Apps (Konnektoren für Drittanbieter-Dienste) und MCP Server (Middleware für Build-Tools und externe Systeme) — in teilbare Workflows. Sie wurden am 26. März 2026 mit über 20 Integrationen veröffentlicht, verfügbar über die Codex-App, CLI und VS Code-Erweiterung.

Wie installiere ich Codex Plugins?

Tippen Sie /plugins in der Codex-App, um das Plugin-Verzeichnis zu durchsuchen. Wählen Sie ein Plugin aus, schließen Sie den Authentifizierungsflow ab, falls erforderlich, und es wird sofort über das @-Symbol verfügbar. Für benutzerdefinierte Plugins erstellen Sie eine Manifest-JSON-Datei, die Ihre Skills und MCP Server deklariert, und verweisen Codex auf die lokale Datei.

Kann ich eigene Codex Plugins bauen?

Ja. Benutzerdefinierte Plugins verwenden eine Manifest-Datei, die Skills (Text-Prompts oder Scripts), App-Konnektoren und MCP Server-Konfigurationen deklariert. Keine Kompilierung nötig — Manifest und Skill-Dateien bearbeiten, lokal installieren und testen. Die Selbstveröffentlichung im offiziellen Plugin-Verzeichnis ist Stand März 2026 noch nicht verfügbar.

Produziert das Build iOS Apps Plugin produktionsreifen Code?

Noch nicht. Das Plugin bewältigt Projekt-Scaffolding, Build-Konfiguration und Multi-Target-Setup gut, und seine Xcode Build MCP-Integration ermöglicht leistungsfähige Build-Test-Zyklen. Aber der generierte UI-Code braucht erhebliche Verfeinerung — rechnen Sie mit Zeit für das Polieren von Layouts, Beheben plattformspezifischer Rendering-Probleme und Optimieren für iOS-Displayeigenschaften.

Wie vergleichen sich Codex Plugins mit Claude Code Skills?

Claude Code Skills bieten tiefere Agent-Koordination und stärkere Schlussfolgerung für komplexe Coding-Aufgaben. Codex Plugins fügen Drittanbieter-App-Konnektoren hinzu (Slack, Figma, Linear) und eine Ein-Klick-Installationserfahrung, die das manuelle MCP-Setup von Claude Code nicht bieten kann. Die beiden Systeme bedienen unterschiedliche Stärken — keines ersetzt das andere vollständig, Stand März 2026.

Lassen Sie uns zusammenarbeiten

Sie möchten AI-Systeme aufbauen, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich helfe gerne.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io