# Was sich im neuen Codex geändert hat – und warum es sich mehr wie eine Entwicklungsumgebung anfühlt

> Canonical: https://vxi.me/de/posts/what-changed-in-the-new-codex/
> Locale: de-de
> Published: 2026-03-27
> Updated: 2026-03-27
> Markdown: https://vxi.me/de/posts/what-changed-in-the-new-codex.md

Wenn dein Bild von Codex noch ungefähr auf dem Stand von Mai 2025 ist, kann die Rückkehr heute etwas irritierend wirken. Es fühlt sich nicht mehr wie dieselbe Art von Produkt an.

Im [Launch-Beitrag zu Codex vom 16. Mai 2025](https://openai.com/index/introducing-codex/) war die Einordnung ziemlich klar: Codex war ein cloudbasierter Software-Engineering-Agent. Das war bereits bedeutend, aber das mentale Modell, das viele Entwickler daraus mitnahmen, war noch relativ einfach. Man übergab eine Aufgabe, Codex erledigte sie in der Cloud und kam mit einem Ergebnis zurück. Der Schwerpunkt lag auf der Ausführung einzelner Tasks.

Heute ist das nicht mehr die ganze Geschichte. Geändert hat sich nicht nur, dass Codex etwas besser programmiert. Der größere Wandel besteht darin, dass das Produkt zunehmend um den Workflow herum wächst: Terminal, IDE, Desktop-App, Skills, Automations, mehrere Agents, Worktrees und dauerhafte Einstiegspunkte. Sobald diese Teile zusammenkommen, wirkt Codex weniger wie ein einzelner Coding-Agent und mehr wie eine Einstiegsebene in eine Entwicklungsumgebung.

Für Entwickler – und für viele Menschen, die heute in irgendeiner Form Vibe Coding betreiben – ist dieser Unterschied wichtig. Er verändert die Nutzung des Tools. Man behandelt Codex nicht mehr nur als etwas, das auf Prompts antwortet, sondern als etwas, das Schritt für Schritt Teile des eigenen Arbeitsablaufs aufnehmen kann.

## Die Timeline macht den Wandel ziemlich deutlich

Am einfachsten erkennt man das, wenn man nicht nach einer einzigen spektakulären Funktion sucht, sondern die Produkt-Meilensteine nebeneinanderlegt.

- Am 16. Mai 2025 veröffentlichte OpenAI [Introducing Codex](https://openai.com/index/introducing-codex/). Der Fokus lag auf einem Cloud-Agent für Softwareentwicklung, der Coding-Aufgaben in einer isolierten Umgebung übernehmen konnte.
- Am 15. September 2025 folgte [Introducing upgrades to Codex](https://openai.com/index/introducing-upgrades-to-codex/). Hier beginnt die Erfahrung über Terminal, IDE, Web und Smartphone hinweg deutlich einheitlicher zu wirken.
- Am 2. Februar 2026 veröffentlichte OpenAI [Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/). Spätestens hier wird die Produktform klarer: App, parallele Agents, Worktrees, Task-Inbox, Skills und Automations. Codex liest sich weniger wie eine Chat-Oberfläche und mehr wie ein Command Center.
- Am 4. März 2026 kam zusätzlich Windows-Support hinzu. Die Multi-Surface-Richtung lässt sich spätestens damit kaum noch übersehen.

Wenn jemand sagt, „das neue Codex hat Skills und pluginartige App-Funktionen bekommen“, verstehe ich, was damit gemeint ist. Trotzdem würde ich es nicht einfach als klassisches Plugin-System beschreiben. Präziser ist: Codex bewegt sich von einer einzelnen Agent-Erfahrung hin zu einer wiederverwendbaren, integrierbaren und orchestrierbaren Entwickler-Workflow-Schicht. OpenAIs eigene Begriffe liegen näher an `Skills`, `Automations`, App-Surfaces und IDE-Integration als an einem traditionellen Plugin-Marktplatz.

## Skills sind wahrscheinlich die wichtigste praktische Veränderung

Wenn AI-Coding-Tools verglichen werden, beginnt die Diskussion oft bei der Modellstärke: Codequalität, Latenz, End-to-End-Fähigkeit. Das alles zählt, aber es ist nicht der Teil, den ich hier am interessantesten finde.

Langfristig wichtiger ist der Teil, den man nicht immer wieder erklären möchte: Repo-Regeln, Coding-Standards, Review-Stil, Deployment-Beschränkungen, Prüfungen vor riskanten Operationen oder projektspezifische Konventionen. In älteren Workflows musste vieles davon in langen Prompts stehen und bei jeder Session neu wiederholt werden. Stabil war das selten.

Genau deshalb sind `Skills` wichtig. Sie sind nicht nur eine weitere Funktion, die man dem Modell angeheftet hat. Sie erlauben, eine wiederholbare Arbeitsweise so zu verpacken, dass sie später erneut aufgerufen werden kann. Für Teams bedeutet das, Prozesse festzuhalten statt sie ständig neu zu erklären. Für Einzelpersonen bedeutet es weniger Prompt-Verschwendung und weniger Drift.

Darum vergleichen viele die Idee intuitiv mit Plugins. Der Vergleich ist nachvollziehbar, aber nur bis zu einem Punkt. Ein klassisches Plugin bedeutet meist „installiere eine Fähigkeit“. Ein Skill liegt näher bei „bewahre eine Methode“. Es geht nicht nur darum, einen Knopf hinzuzufügen. Es geht darum, dem Tool beizubringen, wie in genau dieser Umgebung gearbeitet werden soll.

Für beide Zielgruppen ist der Unterschied relevant. Entwickler wollen, dass das Tool die Regeln des Repos respektiert, statt frei darin herumzuschreiben. Vibe-Coding-Nutzer wollen vermeiden, denselben Kontext bei jedem neuen Lauf wieder von Grund auf aufzubauen.

Bei Skills stehenzubleiben würde allerdings unterschätzen, was sich inzwischen verändert hat. OpenAI hat mittlerweile eine eigene Plugin-Schicht für Codex, und die offizielle Einordnung ist konkreter, als viele vermuten. In den [Codex Plugins docs](https://developers.openai.com/codex/plugins) werden Plugins als installierbare Bundles für wiederverwendbare Codex-Workflows beschrieben. Diese Formulierung ist wichtig. Es geht nicht um „eine kleine Erweiterung installieren und weitermachen“, sondern um ein Paketierungsmodell für wiederholbare Arbeitsweisen.

![Offizieller Screenshot des Codex-Plugin-Verzeichnisses](https://developers.openai.com/images/codex/plugins/directory.png)

Schon der Screenshot liefert einen guten Hinweis. Das neue Codex ist nicht mehr nur „du kannst ein paar Skill-Dateien schreiben, wenn du möchtest“. Es gibt inzwischen ein Plugin-Verzeichnis, Installationsoberflächen, Kategorien und workfloworientierte Einträge. Wenn GitHub, Slack, Linear, Figma, Netlify, Cloudflare und Sentry in einem gemeinsamen Verzeichnis auftauchen, wirkt das Produkt nicht mehr wie ein Coding-Chatbot, sondern eher wie eine Umgebung, in die Distribution bereits eingebaut ist.

Noch wichtiger ist, was ein Plugin bündeln kann. Laut Dokumentation kann ein Plugin drei unterschiedliche Ebenen gemeinsam ausliefern:

- Skills
- Apps, also optionale App-Integrationen oder Connector-Mappings
- MCP-Server für gemeinsam genutzte Tools oder Kontext

Genau deshalb beschreibe ich diese Entwicklung eher als Wandel hin zu einer Entwicklerumgebung als als bloßes Modell-Upgrade. Mit Plugins lebt Wiederverwendbarkeit nicht mehr nur im Prompt. Teams können einen Workflow verpacken, statt ihn jedes Mal neu zu erklären. Einzelpersonen können das Verhalten ihrer Toolchain portabel halten, statt sie ständig neu aufzubauen.

## Plugins machen Skills wirklich verteilbar

Das ist wahrscheinlich der unterschätzteste Teil des Updates.

Vorher blieb selbst ein sehr guter Skill oft persönlich. Man wusste vielleicht, wie man ihn speichert, aufruft und lokal wiederverwendet – aber damit war er noch nicht automatisch für andere leicht auffindbar oder installierbar. Die Plugin-Schicht verändert genau das.

Die offizielle Struktur ist ziemlich eindeutig. Ein minimales Plugin beginnt mit `.codex-plugin/plugin.json` als Einstiegspunkt. Im Plugin-Root können zusätzlich liegen:

- `skills/`
- `.app.json`
- `.mcp.json`
- `assets/`

Das ist auf sehr praktische Weise entwicklerfreundlich. Man teilt nicht länger einen losgelösten Prompt, der irgendwo in einer Notiz steckt. Stattdessen teilt man ein Paket mit Manifest, Metadaten, gebündelten Fähigkeiten, optionalem Text für die Installationsoberfläche und sogar Screenshots. Die Dokumentation geht bis zu Feldern wie `displayName`, `shortDescription`, `defaultPrompt`, `brandColor` und `screenshots`. Das zeigt, dass Plugin-Installation und Discovery bereits als reale Produktoberfläche behandelt werden und nicht nur als vage Zukunftsidee.

Ein weiteres nützliches Detail: OpenAI beschränkt Plugins nicht auf das offizielle Verzeichnis. Codex kann Plugin-Marktplätze an drei Stellen lesen:

- das kuratierte OpenAI-Verzeichnis
- `$REPO_ROOT/.agents/plugins/marketplace.json`
- `~/.agents/plugins/marketplace.json`

Diese Kleinigkeit ist wichtiger, als sie zuerst wirkt. Teams können damit einen repo-lokalen Marketplace für interne Workflows, projektspezifische Skills und Connector-Bundles aufbauen, ohne auf irgendeine öffentliche Ökosystem-Geschichte warten zu müssen. Für Solo-Entwickler und kleine Teams ist das wahrscheinlich ohnehin die realistischste Form des Nutzens.

OpenAI liefert sogar einen eingebauten `@plugin-creator`-Skill aus, um lokale Plugins zu scaffolden. Dieses Detail gefällt mir, weil es zeigt, dass die Funktion tatsächlich zum Benutzen gedacht ist und nicht nur zum Präsentieren.

![Offizieller Screenshot des plugin-creator Skills](https://developers.openai.com/images/codex/plugins/plugin-creator.png)

Noch ein offizielles Signal ist erwähnenswert. Im Beitrag [Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/) schreibt OpenAI, dass sich die gesamte Codex-Nutzung seit dem Start von GPT-5.2-Codex Mitte Dezember verdoppelt habe und im vergangenen Monat mehr als eine Million Entwickler Codex genutzt hätten. Das erklärt, warum Packaging und Distribution plötzlich so relevant werden. Bei dieser Nutzungsskala reicht „schreib einfach einen guten Prompt“ irgendwann nicht mehr. Wiederverwendbare Workflow-Schichten werden Teil der Produktinfrastruktur.

## Beim Unterschied zwischen alt und neu geht es eigentlich um Workflow-Gedächtnis

Meine eigene Lesart ist ziemlich einfach.

Das ältere Codex fühlte sich wie ein sehr leistungsfähiger Cloud-Agent an, dem man Arbeit übergeben konnte. Das war nützlich und teilweise beeindruckend, wirkte aber trotzdem wie externe Hilfe. Viel Kontext hing an der jeweiligen Situation. Nach Abschluss einer Aufgabe musste man beim nächsten Mal oft wieder mit neuen Anweisungen beginnen.

Das neuere Codex scheint auf etwas anderes zu zielen. Natürlich nimmt es weiterhin Tasks entgegen, aber es beginnt auch, Regeln, Oberflächen, Routinen und wiederkehrende Aktionen aufzunehmen. Man kann zwischen Einstiegspunkten wechseln. Skills bleiben wiederverwendbar. Wiederkehrende Arbeit kann an Automations delegiert werden. Die gesamte Form ist dauerhafter.

Für Entwickler senkt das die technische Reibung. Man verbringt weniger Zeit damit, das Repo immer wieder zu erklären, und mehr Zeit damit, reale Arbeit voranzutreiben. Für Vibe-Coding-Nutzer ist der Effekt ähnlich deutlich. Viele scheiterten nicht an Ideen, sondern daran, bei jedem neuen Durchlauf dieselbe Ausgangslage erneut aufbauen zu müssen. Wiederverwendbarkeit verändert das.

Darunter liegt noch ein anderer wichtiger Wandel. Viele ältere AI-Coding-Erfahrungen wirkten wie „starkes Modell, dünne Umgebung“. Das neue Codex versucht klar, die zweite Hälfte dieses Satzes zu verbessern. Es will nicht nur beweisen, dass es Code schreiben kann. Es will zeigen, dass es in einem realistischeren Entwicklungszyklus arbeiten kann.

Das ist eine wesentlich größere Veränderung, als sie auf den ersten Blick wirkt.

## Wer Codex früher genutzt hat, sollte es heute neu einordnen

Ich würde das neue Codex heute etwas anders beurteilen.

Nicht nur danach, ob es eine Funktion schreiben oder ein kleines Feature abschließen kann. Damit verpasst man die eigentliche Bewegung. Die bessere Frage lautet, ob Codex die eigenen Arbeitsregeln aufnehmen und wiederholtes Setup immer weiter reduzieren kann.

Und wenn mit „Plugins“ eigentlich „Möglichkeiten, Workflows zu erweitern oder anzudocken“ gemeint sind, lohnt sich der Blick auf `Skills`, `Automations`, IDE-Integration und die App-Surfaces mehr als die Suche nach einem klassischen Extension Store. Die neue Richtung liegt näher an einer Integrationsschicht als an einem einfachen Plugin-Katalog.

Nach der Lektüre der offiziellen Plugin-Dokumentation würde ich sogar noch weitergehen: Das neue Codex ist nicht mehr nur „pluginartig“. Es besitzt bereits ein echtes Paketierungs- und Marketplace-Modell für Plugins. Es lässt sich nur nicht eins zu eins auf das mentale Modell von Browser- oder VS-Code-Erweiterungen abbilden. Es liegt näher an Workflow-Bundles und Integrationspaketen.

Genau deshalb halte ich diese Entwicklung sowohl für Entwickler als auch für Vibe-Coding-Nutzer für wichtig. Spannend ist nicht nur, dass Codex besser antwortet. Spannend ist, dass es beginnt, sich wie ein Ort zu verhalten, an dem Arbeit fortgesetzt werden kann. Sobald das passiert, liegt der Wert nicht mehr nur in einer einzelnen Antwort, sondern in der Art und Weise, wie sich das Tool schrittweise in den eigenen Prozess einfügt.

Das ist für mich das eigentliche Upgrade. Nicht, dass Codex etwas schneller schreibt, sondern dass es besser darin wird, festzuhalten, **wie** man arbeitet.