skills-directory/codex

Leitfaden zur Codex-Fähigkeit

Ausführen einer Aufgabe

1. Fragen Sie den Benutzer bei einer neuen Sitzung (Fortsetzungen übernehmen das vorherige Modell/den vorherigen Aufwand – siehe Schritt 5) mittels AskUserQuestion, welches Modell UND welchen Reasoning-Aufwand er verwenden möchte, und zwar in einer einzigen Eingabeaufforderung mit zwei Fragen. Wenn der Benutzer keine Präferenz äußert, verwenden Sie standardmäßig gpt-6-astra mit high.
   • Modell – Standard gpt-6-astra:
     • GPT-6: gpt-6-astra (führend / leistungsfähigste – Standard)
     • GPT-5.6: gpt-5.6-sol (zuverlässiges agentisches Arbeitstier), gpt-5.6-terra (ausgewogen, alltäglich), gpt-5.6-luna (schnell & erschwinglich)
     • Legacy (aus Kompatibilitätsgründen beibehalten): gpt-5.5, gpt-5.4, gpt-5.4-mini, gpt-5.3-codex-spark, gpt-5.3-codex
   • Reasoning-Aufwand – Standard high: low, medium, high, xhigh, max, ultra.
     • max/ultra erfordern ein GPT-6- oder GPT-5.6-Modell; ultra ist nur auf astra/sol/terra verfügbar (luna begrenzt auf max); Legacy-Modelle begrenzen auf xhigh.
     • ultra = maximales Reasoning mit automatischer Aufgabenverteilung (langsam und am teuersten – reserviert für die schwierigsten Aufgaben).
     • Wenn der gewählte Aufwand das Maximum des gewählten Modells überschreitet, fallen Sie auf den höchsten unterstützten Aufwand dieses Modells zurück und informieren Sie den Benutzer.
2. Wählen Sie den für die Aufgabe erforderlichen Sandbox-Modus; verwenden Sie standardmäßig --sandbox read-only, es sei denn, Bearbeitungen oder Netzwerkzugriff sind erforderlich.
3. Setzen Sie den Befehl mit den entsprechenden Optionen zusammen:
   • -m, --model <MODEL>
   • --config model_reasoning_effort="<low|medium|high|xhigh|max|ultra>" (max/ultra nur auf GPT-6 / GPT-5.6-Modellen; ultra nur auf astra/sol/terra – siehe Schritt 1)
   • --sandbox <read-only|workspace-write|danger-full-access>
   • --full-auto
   • -C, --cd <DIR>
   • --skip-git-repo-check
   • "Ihre Eingabeaufforderung hier" (als letztes positionsabhängiges Argument)
4. Verwenden Sie immer --skip-git-repo-check.
5. Verwenden Sie bei der Fortsetzung einer vorherigen Sitzung codex exec --skip-git-repo-check resume --last über stdin. Verwenden Sie beim Fortsetzen keine Konfigurationsflags, es sei denn, der Benutzer hat sie explizit angefordert, z. B. wenn er das Modell oder den Reasoning-Aufwand bei der Anforderung zur Fortsetzung einer Sitzung angibt. Syntax für Fortsetzung: echo "Ihre Eingabeaufforderung hier" | codex exec --skip-git-repo-check resume --last 2>/dev/null. Alle Flags müssen zwischen exec und resume eingefügt werden.
6. WICHTIG: Hängen Sie standardmäßig 2>/dev/null an alle codex exec-Befehle an, um Denk-Tokens (stderr) zu unterdrücken. Zeigen Sie stderr nur an, wenn der Benutzer explizit verlangt, Denk-Tokens zu sehen, oder wenn Debugging erforderlich ist.
7. WICHTIG (stdin): codex exec liest immer stdin und verknüpft es mit der positionsabhängigen Eingabeaufforderung – selbst wenn die Eingabeaufforderung vollständig als positionsabhängiges Argument bereitgestellt wird. Wenn stdin nicht geschlossen wird, blockiert codex auf unbestimmte Zeit. Wenn Sie es aus einem Harness aufrufen (Hintergrundaufgaben, Hooks, Skripte, in denen stdin kein TTY, aber auch nicht geschlossen ist), leiten Sie stdin explizit um: Hängen Sie </dev/null an den Befehl an, z. B. codex exec ... "Eingabeaufforderung" </dev/null 2>/dev/null. Symptom, wenn dies falsch gemacht wird: null Bytes stdout, null CPU-Akkumulation, der Prozess scheint auf unbestimmte Zeit zu hängen.
8. Führen Sie den Befehl aus, erfassen Sie stdout/stderr (entsprechend gefiltert) und fassen Sie das Ergebnis für den Benutzer zusammen.
9. Nach Abschluss von Codex informieren Sie den Benutzer: „Sie können diese Codex-Sitzung jederzeit fortsetzen, indem Sie ‚Codex resume‘ sagen oder mich bitten, mit zusätzlichen Analysen oder Änderungen fortzufahren.“

Kurzreferenz

Anwendungsfall	Sandbox-Modus	Wichtige Flags
Schreibgeschützte Überprüfung oder Analyse	read-only	--sandbox read-only 2>/dev/null
Lokale Bearbeitungen anwenden	workspace-write	--sandbox workspace-write --full-auto 2>/dev/null
Netzwerk- oder breiten Zugriff zulassen	danger-full-access	--sandbox danger-full-access --full-auto 2>/dev/null
Kürzliche Sitzung fortsetzen	Von der ursprünglichen übernommen	`echo "Eingabeaufforderung"
Von einem anderen Verzeichnis aus ausführen	Den Aufgabenanforderungen entsprechend	-C <DIR> plus andere Flags 2>/dev/null

Ausführungs-Timeout

Codex produziert keine Zwischenausgabe – es schreibt das Ergebnis nur bei Abschluss. Wenn der Prozess vor Beendigung abgebrochen wird, ist die Ausgabedatei stillschweigend leer (kein Fehler).

Bevorzugter Ansatz: synchron ausführen – dies eliminiert das Timeout-Risiko vollständig, und die Konversation wartet ohnehin auf das Ergebnis.

Bei Ausführung im Hintergrund setzen Sie das Ausführungs-Timeout basierend auf dem Reasoning-Aufwand:

Reasoning-Aufwand	Timeout
low	150s
medium	300s
high	600s
xhigh	1200s
max	1800s
ultra	1800s

Nachverfolgung

• Verwenden Sie nach jedem codex-Befehl sofort AskUserQuestion, um nächste Schritte zu bestätigen, Klarstellungen einzuholen oder zu entscheiden, ob mit codex exec resume --last fortgesetzt werden soll.
• Leiten Sie beim Fortsetzen die neue Eingabeaufforderung über stdin: echo "neue Eingabeaufforderung" | codex exec resume --last 2>/dev/null. Die fortgesetzte Sitzung verwendet automatisch dasselbe Modell, denselben Reasoning-Aufwand und denselben Sandbox-Modus wie die ursprüngliche Sitzung.
• Wiederholen Sie das gewählte Modell, den Reasoning-Aufwand und den Sandbox-Modus, wenn Sie Folgeaktionen vorschlagen.

Kritische Bewertung der Codex-Ausgabe

Codex wird von OpenAI-Modellen betrieben, die ihre eigenen Wissensgrenzen und Einschränkungen haben. Behandeln Sie Codex als Kollegen, nicht als Autorität.

Richtlinien

• Vertrauen Sie Ihrem eigenen Wissen, wenn Sie sich sicher sind. Wenn Codex etwas behauptet, von dem Sie wissen, dass es falsch ist, widersprechen Sie direkt.
• Recherchieren Sie Meinungsverschiedenheiten mithilfe von WebSearch oder Dokumentation, bevor Sie Codex' Behauptungen akzeptieren. Teilen Sie die Ergebnisse bei Bedarf über eine Fortsetzung mit Codex.
• Denken Sie an Wissensgrenzen – Codex weiß möglicherweise nichts über aktuelle Veröffentlichungen, APIs oder Änderungen, die nach seinen Trainingsdaten aufgetreten sind.
• Übernehmen Sie nicht blind – Codex kann falsch liegen. Bewerten Sie seine Vorschläge kritisch, insbesondere in Bezug auf:
  • Modellnamen und -fähigkeiten
  • Aktuelle Bibliotheksversionen oder API-Änderungen
  • Best Practices, die sich möglicherweise weiterentwickelt haben

Wenn Codex falsch liegt

1. Formulieren Sie Ihre Meinungsverschiedenheit klar gegenüber dem Benutzer
2. Liefern Sie Beweise (eigenes Wissen, Websuche, Dokumentation)
3. Setzen Sie optional die Codex-Sitzung fort, um die Meinungsverschiedenheit zu besprechen. Identifizieren Sie sich als Claude, damit Codex weiß, dass es sich um eine Diskussion zwischen gleichrangigen KIs handelt. Verwenden Sie Ihren tatsächlichen Modellnamen (z. B. das Modell, unter dem Sie derzeit laufen) anstelle eines fest codierten Namens:

   echo "Dies ist Claude (<Ihr aktueller Modellname>) zur Nachverfolgung. Ich widerspreche [X] wegen [Beweis]. Was ist Ihre Meinung dazu?" | codex exec --skip-git-repo-check resume --last 2>/dev/null
   

4. Rahmen Sie Meinungsverschiedenheiten als Diskussionen ein, nicht als Korrekturen – jede KI könnte falsch liegen
5. Lassen Sie den Benutzer entscheiden, wie fortgefahren werden soll, wenn es echte Uneindeutigkeit gibt

Fehlerbehandlung

• Stoppen Sie und melden Sie Fehler, wenn codex --version oder ein codex exec-Befehl mit einem Exit-Code ungleich Null beendet wird; fordern Sie vor einem erneuten Versuch eine Anweisung an.
• Bevor Sie stark wirkende Flags (--full-auto, --sandbox danger-full-access, --skip-git-repo-check) verwenden, fragen Sie den Benutzer mit AskUserQuestion um Erlaubnis, es sei denn, diese wurde bereits erteilt.
• Wenn die Ausgabe Warnungen oder Teilergebnisse enthält, fassen Sie diese zusammen und fragen Sie mit AskUserQuestion, wie angepasst werden soll.