Werkzeuge · Einordnung
Codex oder Claude Code?
Der Vergleich für den Arbeitsalltag.
Beide Werkzeuge können Dateien ändern, Befehle ausführen und über längere Aufgaben hinweg arbeiten. Die Auswahl entscheidet sich selten an einer einzelnen Antwort. Wichtiger sind die Umgebung, in der das Team arbeitet, und wie Regeln, Wissen und Zugriffe darin landen.
Der Kurzvergleich
| Frage | Codex | Claude Code |
|---|---|---|
| Am Smartphone arbeiten? | Ja, mit Einschränkung. Über die ChatGPT-App lassen sich unterstützte Codex-Sitzungen fernsteuern. Dafür muss derzeit ein Codex-Host auf macOS wach, online und geöffnet bleiben. | Ja. Die Claude-App kann Cloud-Sitzungen starten und steuern oder eine lokale Sitzung per Remote Control bedienen. Die App ist dabei Client, nicht die Rechenumgebung. |
| Ohne eigenen Rechner weiterarbeiten? | Für die dokumentierte Mobil-Fernsteuerung: nein, der verbundene Mac ist die Arbeitsumgebung. | Ja, bei Cloud-Sitzungen. Sie laufen in einer verwalteten Cloud-Umgebung weiter, auch wenn der Laptop zu ist. Das Repository muss dafür erreichbar sein, typischerweise über GitHub. |
| Skills im Projekt | Skills sind wiederverwendbare Anleitungen. Sie können eigenständig vorliegen oder Teil eines Plugins sein. | Ja. Projekt-Skills liegen beispielsweise unter .claude/skills/; Claude lädt sie bei passender Aufgabe oder auf Aufruf. |
| Skills verteilen | Über Plugins: Ein Plugin kann Skills, verbundene Apps und App-Templates bündeln. Einzelne Plugins können auch nur Skills enthalten. | Über Plugins und Marketplaces. Ein Plugin kann Skills, Agents, Hooks, MCP-Server und weitere Komponenten enthalten. |
| Externe Systeme anbinden | Plugins können Connected Apps enthalten, etwa für Suche oder erlaubte Aktionen in anderen Diensten. Die Rechte des angebundenen Kontos bleiben maßgeblich. | MCP ist der zentrale Anschluss für externe Tools und Daten. Plugins können MCP-Server mitliefern. |
| Arbeitsflächen | Desktop-App, CLI und IDE-Erweiterung; die mobile Nutzung ist derzeit eine Fernsteuerung unterstützter Desktop-Sitzungen. | CLI, Desktop, VS Code, JetBrains, Web und Mobile. Der Funktionsumfang ist je Oberfläche unterschiedlich. |
„Ja“ bei Mobil heißt in beiden Fällen nicht: Das Telefon kompiliert den Code. Es dient als Oberfläche für eine Sitzung, die auf dem Rechner oder in der Cloud arbeitet.
Mobil: der Unterschied steckt im Startpunkt
Wer unterwegs nur Ergebnisse prüfen, Rückfragen beantworten oder Freigaben geben will, kann beide nutzen. Bei Codex verbindet die ChatGPT-App das Telefon mit einer laufenden Codex-Instanz auf einem Mac. Dort sieht man auch Projektkontext, Terminal-Ausgabe, Diffs und Testergebnisse. Das ist praktisch, wenn der eigene Rechner ohnehin die Arbeitsumgebung ist.
Claude Code bietet zusätzlich eine Cloud-Variante. Eine Aufgabe kann direkt vom Telefon aus für ein Repository und einen Branch gestartet werden; die Sitzung läuft anschließend in einer Cloud-Umgebung weiter. Für lokalen Dateizugriff gibt es auch dort Remote Control. Wer abends ein Ticket anstoßen möchte, ohne dass der eigene Laptop laufen muss, hat bei Claude Code damit den geraderen Weg.
Die Kehrseite gehört dazu: Cloud-Sitzungen brauchen eine sauber vorbereitete Umgebung, passende Repository-Rechte und klare Regeln für Netzwerkzugriff und Secrets. Das ist weniger eine Frage des besseren Agenten als der eigenen Betriebsentscheidung.
Skills: beide kennen das Prinzip, die Verpackung ist anders
Ein Skill hält eine wiederverwendbare Arbeitsanleitung fest: Welche Dateien prüft der Agent bei einer Migration? Welche Tests sind vor einem Release Pflicht? Wie wird ein Incident dokumentiert? Genau diese Abläufe sollte ein Team nicht jedes Mal neu in den Chat schreiben.
Claude Code trennt früh zwischen dem lokalen beziehungsweise projektbezogenen Ordner .claude/ und einem Plugin für die Verteilung. Für ein einzelnes Repository reicht eine Skill-Datei. Sobald dieselbe Regel in mehreren Projekten oder im Team gebraucht wird, kann sie als Plugin mit eigenem Manifest und Namespace verteilt werden.
Auch in Codex können Skills unabhängig arbeiten oder in Plugins stecken. Der Unterschied ist stärker organisatorisch: Das Plugin-Verzeichnis bündelt wiederverwendbare Anleitung, verbundene Apps und gegebenenfalls App-Templates. Für Teams mit vielen SaaS-Anbindungen kann das angenehm sein, weil Zugriff und Installation an einem Ort zusammenlaufen. Die Freigaben der einzelnen App gelten trotzdem weiter.
Plugins und MCP: zwei Wege zum selben Ziel
Beide Produkte lassen sich über den Standard MCP mit Werkzeugen und Datenquellen verbinden. Claude Code macht diese Ebene sehr sichtbar: MCP-Server, Hooks, Agents und Skills sind getrennte Bausteine, die Plugins zusammenfassen können. Das passt gut zu Teams, die ihre Entwicklerumgebung als Code konfigurieren und in Git versionieren wollen.
Bei Codex ist ein Plugin eher ein Paket für den Arbeitsablauf. Es kann reine Skills enthalten, aber auch Connected Apps und deren Einrichtung begleiten. Das kommt Teams entgegen, die neben dem Repository regelmäßig Dokumentation, Tickets oder Systeme wie CRM und Cloud-Speicher einbeziehen möchten. Die Frage lautet dann nicht nur „Kann der Agent die Daten lesen?“, sondern auch: Wer darf die Verbindung installieren, was darf sie schreiben und wie wird sie geprüft?
Wofür ich welches Werkzeug zuerst prüfen würde
Codex passt eher, wenn …
- das Team bereits tief im ChatGPT-Ökosystem arbeitet und die Desktop-App nutzen möchte;
- Apps und Plugins über gemeinsame Workspace-Regeln bereitgestellt werden sollen;
- der eigene Rechner oder eine lokale Entwicklungsumgebung der natürliche Arbeitsort bleibt;
- mobile Nutzung vor allem bedeutet, laufende Arbeit zu verfolgen und Entscheidungen zu treffen.
Claude Code passt eher, wenn …
- Terminal, IDE und Git-basierte Konfiguration im Mittelpunkt stehen;
- Cloud-Aufgaben ohne eingeschalteten Laptop weiterlaufen sollen;
- Skills, Hooks, Agents und MCP-Server als getrennte, versionierte Bausteine gepflegt werden;
- die Wahl zwischen CLI, Desktop, Web und Mobile für verschiedene Arbeitsweisen wichtig ist.
Das ist keine Qualitätsrangliste. Beide Werkzeuge können beim gleichen Ticket unterschiedlich gut abschneiden, je nach Codebasis, Kontext, Prompt und Prüfschritten. Ein kurzer Pilot mit echten Aufgaben ist aussagekräftiger als ein Duell an einer Demo-App.
Der sinnvollere Auswahltest
Statt zwei Wochen lang dasselbe künstliche Feature bauen zu lassen, würde ich fünf bis zehn echte, gut abgegrenzte Aufgaben wählen: einen Bug mit Test, eine kleine Erweiterung, eine Dokumentationsänderung, eine Suche über die Codebasis und eine Aufgabe mit einem externen System. Für beide Kandidaten gelten dieselben Repository-Regeln, derselbe Testbefehl und dieselbe Review-Praxis.
| Messen | Warum es zählt |
|---|---|
| Durchlaufzeit bis zum reviewbaren Diff | Zeigt, ob der Ablauf Arbeit abnimmt oder nur Arbeit verlagert. |
| Nacharbeit im Review | Viele schnelle erste Entwürfe sind wertlos, wenn die Korrektur anschließend länger dauert. |
| Fehlgeschlagene Befehle und Rückfragen | Sie machen sichtbar, ob Projektkontext, Skills und Berechtigungen fehlen. |
| Umgebungsaufwand | Cloud, lokale Tools, Secrets und Freigaben gehören zur Kostenrechnung dazu. |
| Akzeptanz im Team | Ein Werkzeug, das nur eine Person bedienen kann, wird keine gemeinsame Arbeitsweise. |
Nach dem Pilot ist die Entscheidung meist konkreter: Braucht das Team vor allem einen Agenten im Terminal, eine Cloud-Arbeitsfläche oder eine enge Verbindung zu bestehenden ChatGPT-Apps? Erst danach lohnt es sich, Plugins und Integrationen breiter auszurollen.
Quellen
OpenAI: Plugins in ChatGPT and Codex · Skills, Apps, Installation und Berechtigungen.
OpenAI: ChatGPT Release Notes · Codex Remote Access in der mobilen ChatGPT-App.
Anthropic: Claude Code on mobile · Cloud-Sitzungen, Remote Control und Einschränkungen.
Anthropic: Create plugins · Plugin-Struktur und Skills in Claude Code.
Anthropic: Platforms and integrations · verfügbare Arbeitsflächen und Unterschiede.
Welcher Agent passt zu Ihrem Team?
Ich schaue mit Ihnen auf Repository, Arbeitsabläufe und Sicherheitsanforderungen und setze einen kleinen, messbaren Pilot auf.
Robin.Steltmann@googlemail.com