Codex startet Unterstützung für Subagents

• OpenAI Codex unterstützt jetzt Subagent-Workflows und kann komplexe Aufgaben parallel auf mehrere spezialisierte Agenten verteilen und die Ergebnisse zu einer Antwort zusammenführen
• Subagenten werden nur erstellt, wenn der Nutzer dies ausdrücklich anfordert; da jeder Agent eigenständig Modelle und Tools verwendet, ist der Token-Verbrauch höher als bei einem einzelnen Agenten
• Benutzerdefinierte Agenten lassen sich per TOML-Datei definieren, sodass Modell, Sandbox-Modus, MCP-Server usw. pro Agent unabhängig konfiguriert werden können
• Ebenfalls enthalten ist die experimentelle Funktion spawn_agents_on_csv, die für jede Zeile einer CSV-Datei Worker-Agenten stapelweise erzeugt und jede Zeile als eigene Arbeitseinheit behandelt
• Die offizielle Dokumentation zeigt direkt Muster zur Kombination benutzerdefinierter Agenten für reale Szenarien wie Code-Reviews oder Frontend-Debugging

---

Überblick und Verfügbarkeit von Subagenten

• Codex unterstützt Subagent-Workflows, bei denen spezialisierte Agenten parallel erzeugt (spawned) und ihre Ergebnisse in einer einzigen Antwort gesammelt werden
• Besonders nützlich ist das für komplexe Aufgaben mit hoher Parallelität, etwa das Erkunden einer Codebasis oder die Planung einer mehrstufigen Feature-Implementierung
• In Subagent-Workflows lassen sich je nach Aufgabe auch benutzerdefinierte Agenten mit unterschiedlichen Modellkonfigurationen und Anweisungen definieren
• In der aktuellen Codex-Version sind Subagent-Workflows standardmäßig aktiviert
• Subagent-Aktivitäten sind derzeit in der Codex-App und CLI sichtbar; Sichtbarkeit in der IDE-Erweiterung folgt in Kürze
• Subagenten werden nur erzeugt, wenn der Nutzer dies ausdrücklich anfordert; da jeder Subagent eigene Modell- und Tool-Aufgaben ausführt, ist der Token-Verbrauch höher als bei der Ausführung mit einem einzelnen Agenten

Allgemeiner Workflow

• Codex übernimmt die Orchestrierung zwischen Agenten: neue Subagenten erzeugen, Folgeanweisungen weiterleiten, auf Ergebnisse warten und Agent-Threads beenden
• Wenn mehrere Agenten laufen, wartet Codex, bis alle Anfrageergebnisse vorliegen, und gibt dann eine konsolidierte Antwort zurück
• Beispiel-Prompt: Für den aktuellen PR jeweils einen Agenten pro Bereich für Sicherheitsprobleme, Codequalität, Bugs, Race Conditions, instabile Tests und Wartbarkeit erzeugen und anschließend das Gesamtergebnis zusammenfassen

Verwaltung von Subagenten

• In der CLI kann mit dem Befehl /agent zwischen aktiven Agent-Threads gewechselt und laufende Threads geprüft werden
• Man kann Codex direkt anweisen, laufende Subagenten zu steuern, zu stoppen oder abgeschlossene Threads zu beenden

Freigaben und Sandbox-Kontrolle

• Subagenten erben die aktuelle Sandbox-Richtlinie des Nutzers
• In interaktiven CLI-Sitzungen können Freigabeanfragen inaktiver Agent-Threads auch dann angezeigt werden, wenn der Haupt-Thread verwendet wird; im Freigabe-Overlay erscheint ein Label des Quell-Threads
  • Mit o lässt sich der betreffende Thread öffnen, um freizugeben, abzulehnen oder zu antworten
• In nicht interaktiven Abläufen können neue Freigaben nicht angezeigt werden; daher schlagen freigabepflichtige Aufgaben fehl und der Fehler wird an den übergeordneten Workflow weitergegeben
• Beim Erzeugen eines Child-Agenten werden die Live-Runtime-Overrides des Parent-Turns erneut angewendet, einschließlich Änderungen durch /approvals oder interaktive Einstellungen wie --yolo
  • Selbst wenn die ausgewählte benutzerdefinierte Agent-Datei andere Standardwerte setzt, haben die Einstellungen des Parent Vorrang
• Für einzelne benutzerdefinierte Agenten lassen sich Sandbox-Einstellungen separat überschreiben (z. B. ein bestimmter Agent im Nur-Lese-Modus)

Benutzerdefinierte Agenten

• Codex stellt drei standardmäßig integrierte Agenten bereit
  • default: allgemeiner Fallback-Agent
  • worker: ausführungsorientierter Agent mit Fokus auf Implementierung und Korrekturen
  • explorer: leseorientierter Agent zum Erkunden der Codebasis
• Für benutzerdefinierte Agenten werden separate TOML-Dateien unter ~/.codex/agents/ (persönlich) oder .codex/agents/ (projektweit) abgelegt
• Jede Datei definiert genau einen benutzerdefinierten Agenten, den Codex als Konfigurationsebene für die Erzeugungssitzung lädt
• Pflichtfelder, die in allen benutzerdefinierten Agent-Dateien enthalten sein müssen:
  • name, description, developer_instructions
• Optionale Felder wie nickname_candidates, model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.config usw. werden bei Auslassung aus der Parent-Sitzung geerbt

Globale Konfiguration

• Die globale Konfiguration für Subagenten wird im Abschnitt [agents] der Konfigurationsdatei definiert
• agents.max_threads: Obergrenze für gleichzeitig geöffnete Agent-Threads (Standardwert 6)
• agents.max_depth: Schachtelungstiefe erzeugter Agenten (Standardwert 1, erlaubt nur direkte Child-Agenten und verhindert tiefere Verschachtelung)
• agents.job_max_runtime_seconds: Standard-Timeout pro Worker für spawn_agents_on_csv-Jobs (falls nicht gesetzt, standardmäßig 1800 Sekunden pro Aufruf)
• Wenn ein benutzerdefinierter Agent denselben Namen wie ein integrierter Agent wie explorer hat, hat der benutzerdefinierte Agent Vorrang

Schema für benutzerdefinierte Agent-Dateien

• name (string, Pflicht): der Agentenname, den Codex beim Erzeugen oder Referenzieren des Agenten verwendet
• description (string, Pflicht): für Menschen gedachte Anleitung, wann Codex diesen Agenten verwenden soll
• developer_instructions (string, Pflicht): die zentralen Anweisungen, die das Verhalten des Agenten definieren
• nickname_candidates (string[], optional): Pool von angezeigten Spitznamen für erzeugte Agenten
• Andere unterstützte config.toml-Schlüssel wie model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.config usw. können ebenfalls enthalten sein
• Codex identifiziert Agenten über das Feld name; den Dateinamen daran anzugleichen ist die einfachste Konvention, aber das Feld name ist die maßgebliche Quelle

Angezeigte Spitznamen

• nickname_candidates dienen dazu, in der UI unterscheidbare Labels anzuzeigen, wenn mehrere Instanzen desselben benutzerdefinierten Agenten laufen
• Spitznamen sind nur für die Anzeige gedacht; Codex identifiziert und erzeugt Agenten weiterhin über name
• Kandidaten für Spitznamen müssen eine nicht leere Liste eindeutiger Namen sein und dürfen ASCII-Zeichen, Zahlen, Leerzeichen, Bindestriche und Unterstriche enthalten
• Beispiel: Werden für den Agenten reviewer die Spitznamen ["Atlas", "Delta", "Echo"] gesetzt, dann werden in App und CLI die Spitznamen angezeigt, der zugrunde liegende Agent-Typ bleibt jedoch reviewer

Beispiel 1: Muster für PR-Reviews

• Ein Muster, das das Review auf drei spezialisierte benutzerdefinierte Agenten aufteilt
  • pr_explorer: Nur-Lese-Agent zum Mappen der Codebasis und Sammeln von Belegen (Modell: gpt-5.3-codex-spark, reasoning effort: medium)
  • reviewer: PR-Reviewer zum Finden von Korrektheits-, Sicherheits- und Test-Risiken (Modell: gpt-5.4, reasoning effort: high)
  • docs_researcher: Dokumentationsspezialist, der über einen dedizierten MCP-Server Framework- oder API-Dokumentation prüft (Modell: gpt-5.3-codex-spark, Nur-Lese-Modus)
• Projektkonfiguration: max_threads = 6, max_depth = 1
• Anweisungen für pr_explorer: Im Explorationsmodus bleiben, tatsächliche Ausführungspfade verfolgen, Dateien und Symbole zitieren und keine Änderungsvorschläge machen, sofern der Parent-Agent dies nicht anfordert
• Anweisungen für reviewer: Aus Sicht des Owners reviewen, Korrektheit, Sicherheit, Verhaltensregressionen und fehlende Testabdeckung priorisieren, wenn möglich Reproduktionsschritte angeben und reine Stilkommentare vermeiden, sofern sie keinen echten Bug verdecken
• Anweisungen für docs_researcher: Den Docs-MCP-Server nutzen, um APIs, Optionen und versionsspezifisches Verhalten zu prüfen, und knapp mit Links oder exakten Verweisen antworten; keine Codeänderungen
• Beispiel-Prompt: "Diesen Branch im Vergleich zu main reviewen. pr_explorer soll betroffene Codepfade mappen, reviewer reale Risiken finden und docs_researcher die vom Patch verwendeten Framework-APIs validieren"

CSV-Stapelverarbeitung: spawn_agents_on_csv (experimentell)

• Experimentelle Funktion, die sich künftig ändern kann
• Bei vielen ähnlichen Aufgaben wird jede CSV-Zeile als eigene Arbeitseinheit verwendet, um Worker-Subagenten stapelweise zu erzeugen
• Codex liest die CSV, erzeugt pro Zeile einen Worker-Agenten, wartet auf den Abschluss des gesamten Batches und exportiert die Ergebnisse als CSV
• Geeignete Anwendungsfälle:
  • Pro Zeile jeweils eine Datei, ein Paket oder einen Service reviewen
  • Eine Liste von Incidents, PRs oder Migrationszielen prüfen
  • Für viele ähnliche Eingaben strukturierte Zusammenfassungen erzeugen
• Eingabeparameter des Tools: csv_path (Quell-CSV), instruction (Prompt-Vorlage für Worker, mit {column_name}-Platzhaltern), id_column (stabile Element-ID), output_schema (festes JSON-Format), output_csv_path, max_concurrency, max_runtime_seconds
• Jeder Worker muss report_agent_job_result genau einmal aufrufen; endet er ohne Ergebnisbericht, wird die betreffende Zeile als Fehler markiert
• Bei Ausführung mit codex exec wird während des Batch-Laufs in stderr eine einzeilige Fortschrittsaktualisierung angezeigt
• Die exportierte CSV enthält die Original-Zeilendaten sowie Metadaten wie job_id, item_id, status, last_error, result_json
• Relevante Runtime-Einstellungen: agents.max_threads (Obergrenze gleichzeitiger Threads), agents.job_max_runtime_seconds (Timeout pro Worker, wobei max_runtime_seconds pro Aufruf Vorrang hat), sqlite_home (SQLite-Pfad zur Statusspeicherung für Agent-Jobs und Exportergebnisse)

Beispiel 2: Muster für integriertes Frontend-Debugging

• Ein nützliches Muster für UI-Regressionen, instabile Browser-Flows und integrierte Bugs, die Anwendungscode und das laufende Produkt zugleich betreffen
• Kombination aus drei benutzerdefinierten Agenten:
  • code_mapper: Nur-Lese-Explorationsagent zum Finden relevanter Frontend- und Backend-Codepfade (Modell: gpt-5.3-codex-spark, reasoning effort: medium)
  • browser_debugger: UI-Debugger, der mit Browser-Tools Probleme reproduziert und Belege erfasst (Modell: gpt-5.4, reasoning effort: high, Sandbox: workspace-write)
    • Nutzt Browser-Tools für Screenshots, Konsolenausgaben und Netzwerkbelege; Änderungen am Anwendungscode sind untersagt
    • Verbindung zu einem Chrome-DevTools-MCP-Server (http://localhost:3000/mcp, startup_timeout_sec: 20)
  • ui_fixer: implementierungsorientierter Agent für kleine, gezielte Korrekturen, sobald das Problem verstanden ist (Modell: gpt-5.3-codex-spark, reasoning effort: medium)
    • Führt die kleinste vertretbare Änderung durch, fasst keine nicht relevanten Dateien an und prüft nur das geänderte Verhalten
• Beispiel-Prompt: "Untersuchen, warum das Einstellungs-Modal nicht speichern kann. browser_debugger soll das Problem reproduzieren, code_mapper die zugehörigen Codepfade verfolgen und ui_fixer nach Identifikation des Fehlermodus eine minimale Korrektur implementieren"

[kgcrom]

Der Agent verwendet nur das Modell GPT-5.1-Codex-Mini,
aber wenn man in den Custom Instructions der Codex App
den folgenden Prompt hinzufügt, arbeitet der Agent mit GPT-5.3-Codex-Spark.

"- when it spawns agents, use models "GPT-5.3-Codex-Spark" or higher."

Außerdem macht es durchaus Spaß, beim Erstellen von Agents das Modell festzulegen,
und ich finde es gut, dass die Codex App die Struktur in Unterordnern anzeigt.

[hmmhmmhm]

Ich habe bei einer krassen Rabattaktion auf KakaoTalk zugeschlagen und nutze es seitdem wirklich super gerne, haha.

[shakespeares]

Schade, vielleicht gibt es also wieder keine Veranstaltung? seufz

[xguru]

Codex, bitte baut auch schnell eine Fernsteuerung!