Claude Code baut. Codex prüft: so orchestrierst du beide ohne Agentenchaos

Dieser Beitrag erweitert die Anleitung „Claude Code einrichten: vom Terminal zum eigenen Autopiloten“. Dort entsteht das Grundsystem aus Regeln, Skills, Unteragenten, Hooks und überprüfbaren Schleifen. Hier kommt eine zweite technische Perspektive hinzu: Codex prüft Änderungen unabhängig, ohne einen zweiten Arbeitsprozess zu eröffnen.

Das Ziel ist kein Agenten-Zoo. Es ist eine klare Arbeitsteilung. Claude Code bleibt der primäre ausführende Agent im Repository. Codex liest den Diff, sucht konkrete Defekte und liefert Befunde mit Datei, Beleg und begrenztem Fix. Tests, Build, Browser und Git entscheiden, ob eine Änderung wirklich trägt.

warum kein zweiter loop entsteht

Das bestehende System hat bereits eine vollständige Führungskette. In DEFINE werden Ziel, Scope, Nicht-Ziele, Akzeptanzkriterien und notwendige Prüfungen geklärt. PLAN übersetzt das in betroffene Module, Risiken und minimale Schritte. BUILD erzeugt den Diff. VERIFY führt die passenden technischen Prüfungen aus. REVIEW sucht unabhängig nach Fehlern. SHIP verlangt einen verständlichen Status und eine ausdrückliche Freigabe.

Codex bekommt deshalb keinen eigenen parallelen Ablauf. Ein zweiter Master-Loop würde Ziele doppelt definieren, Zuständigkeiten vermischen und bei widersprüchlichen Ergebnissen eine weitere Entscheidungsebene verlangen. Codex tritt genau in REVIEW ein. Sein Eingang ist ein begrenzter Diff mit Regeln und Prüffokus. Sein Ausgang ist eine Liste belegter Befunde. Die Entscheidung über Annahme, Fix und erneute Verifikation bleibt im führenden Ablauf.

Die Formel ist bewusst knapp: Claude Code baut. Codex prüft. Skills strukturieren wiederkehrende Schritte. Subagents übernehmen begrenzte Fachaufgaben. Hooks sichern frühe Mindestprüfungen. Die Wahrheit liegt in ausführbaren Belegen.

rollen und grenzen

Claude Code ist der primäre Repo-Executor. Es liest die relevanten Dateien, plant, ändert Code und führt die passenden Checks aus. Anthropic beschreibt Claude Code als agentisches Coding-Werkzeug, das Codebasen lesen, Dateien bearbeiten und Befehle ausführen kann. Die offizielle Übersicht ordnet Regeln, Skills, Subagents und Hooks als unterschiedliche Erweiterungspunkte ein.

Codex ist in diesem Modell der unabhängige technische Reviewer. OpenAI beschreibt für Codex anpassbare Review-Regeln über AGENTS.md und einen auf konkrete Fehler ausgerichteten Review-Prozess. Der read-only-Modus ist hier ausdrücklich eine Betriebsregel dieses Systems. Er ist keine allgemeine Aussage über den Produktstandard von Codex.

ChatGPT ist nicht Teil des automatisierten Repo-Ablaufs. Es gibt kein ChatGPT-Handoff, keinen Runtime-Agenten und keine ChatGPT-Schicht zwischen Claude Code und Codex. Die Dateien unter .ai/ dokumentieren Entscheidungen, Locks, Review-Aufträge und technische Übergaben innerhalb des Repository-Prozesses.

was die rollen praktisch bedeuten

Rolle	Darf	Darf standardmäßig nicht
Claude Code	im freigegebenen Scope planen, schreiben und prüfen	ungefragt deployen, committen, Secrets lesen oder fremde Scopes ändern
Codex	Diff und Regeln lesen, Defekte mit Belegen melden	Dateien ändern, Scope erweitern, committen oder deployen
Tools	Zustand und Ergebnis messbar machen	eine fachliche Freigabe ersetzen

die zielstruktur im repository

Vor jeder Ergänzung wird geprüft, was bereits vorhanden ist. Keine Datei wird blind überschrieben. Ein bestehendes AGENTS.md bleibt maßgeblich und wird gezielt ergänzt. Dasselbe gilt für CLAUDE.md, Hook-Konfiguration und vorhandene Skills.

AGENTS.md
CLAUDE.md
.claude/
  skills/
    orchestrate/SKILL.md
    verify-change/SKILL.md
    review-diff/SKILL.md
    request-codex-review/SKILL.md
    consume-codex-review/SKILL.md
    ship-gate/SKILL.md
  agents/
    codebase-explorer.md
    architecture-planner.md
    implementation-worker.md
    diff-reviewer.md
    ui-ux-reviewer.md
    brand-gate.md
    release-gate.md
  hooks/
    post-edit-check.sh
.ai/
  codex/
  decisions/
  handoffs/
  locks/
  context/
  templates/
docs/
  ai/
    AI-OPERATING-MODEL.md
    CODEX-ORCHESTRATION.md

Die Verzeichnisse sind eine Zielstruktur, keine Pflicht zum Anlegen leerer Ordner. Angelegt wird, was der aktuelle Ablauf wirklich nutzt. .ai/codex/ hält Review-Aufträge und Ergebnisse. .ai/decisions/ dokumentiert technische Entscheidungen. .ai/locks/ macht aktive Schreibbereiche sichtbar. Die Struktur speichert weder Secrets noch API-Schlüssel.

AGENTS.md als gemeinsames grundgesetz

OpenAI dokumentiert, dass Codex Anweisungen aus AGENTS.md berücksichtigt. Genau deshalb gehört der gemeinsame Workflow in diese Datei. Sie beschreibt Regeln, die für den ausführenden Agenten und den Reviewer gleichermaßen gelten: Scope schützen, keine Secrets lesen, keine ungefragten Commits oder Deployments und keine parallelen Schreibzugriffe im selben Bereich.

Der folgende Kern ist bewusst kompakt. Ergänzt ihn an euren Bestand, statt eine vorhandene Datei zu ersetzen.

# Repository Agent Instructions

## Master Workflow

All agents must follow the existing workflow:

DEFINE → PLAN → BUILD → VERIFY → REVIEW → SHIP

This workflow is authoritative.

## Roles

Claude Code is the primary implementation agent.
Codex is an independent technical reviewer by default.
Codex must be read-only unless the user explicitly assigns Codex an isolated implementation task.

## Scope Control

Do not:
- make unrelated changes
- refactor without explicit need
- deploy without explicit approval
- commit without explicit approval
- read or expose secrets
- modify .env files
- change public APIs without explicit instruction
- work on a locked scope
- let multiple agents write in the same scope simultaneously

## Workflow Rules

DEFINE clarifies goal, scope, non-goals, acceptance criteria and verification.
PLAN inspects relevant files, affected modules, risks and checks.
BUILD keeps implementation minimal and scoped.
VERIFY runs git diff --check, targeted tests, typecheck, lint, build and UI checks as relevant.
REVIEW uses Claude diff-reviewer and Codex for independent technical review when needed.
SHIP requires resolved reviews, understood checks, a clean scope, no conflicting lock and user approval.

## Final Response

Always report changed files, summary, verification, remaining risks and Codex review status.

CLAUDE.md für die ausführung

CLAUDE.md übersetzt das gemeinsame Grundgesetz in Claude-spezifische Entscheidungen. Die Datei legt fest, wann ein Skill oder Subagent eingesetzt wird und welche Aufgaben klein genug für die direkte Bearbeitung sind. Nach Anthropics offizieller Dokumentation sind Skills wiederverwendbare Arbeitsanweisungen, Subagents getrennte Fachkontexte und Hooks deterministische Aktionen an Ereignispunkten. Diese Bausteine unterstützen den Master-Loop. Sie ersetzen ihn nicht.

Codex bleibt auch hier Reviewer. Claude Code verifiziert jeden Befund, bevor es eine Zeile ändert. Ein überzeugend formulierter Hinweis ohne Codebeleg ist kein akzeptierter Fehler.

# Claude Code Operating Mode

Claude Code is the primary repo executor.

The master workflow is:

DEFINE → PLAN → BUILD → VERIFY → REVIEW → SHIP

Use internal orchestration only to support this workflow. Do not create a competing workflow.

## Skill Mapping

- /orchestrate during PLAN and multi-step work
- /verify-change during VERIFY
- /review-diff during REVIEW
- /request-codex-review for independent technical review
- /consume-codex-review when Codex findings exist
- /ship-gate before SHIP

## Codex Policy

Codex is used as an independent technical reviewer.

Our default operating rule:
- read-only
- defect-first
- diff-based
- no file edits
- no commits
- no deploys

Claude Code verifies Codex findings before applying them.
Reject speculative, out-of-scope, style-only, pre-existing unrelated or rule-conflicting findings.

ein unabhängiges Codex-Review anfordern

Ein Review-Auftrag braucht weniger Kontext als eine Implementierung, aber mehr Präzision als „schau mal drüber“. Vor dem Auftrag werden Status, Diff-Statistik und Whitespace-Prüfung erhoben. Der Request nennt Task, Scope, geänderte Dateien und Review-Fokus. Große Roh-Diffs, Logs und sensible Werte bleiben draußen.

Der Skill schreibt den Auftrag nach .ai/codex/YYYY-MM-DD-<slug>-review-request.md. Damit ist später nachvollziehbar, welche Version und welche Grenzen geprüft werden sollten.

---
description: Prepare an independent read-only Codex review request for the current diff.
---

# Request Codex Review

Prepare a read-only Codex review request. Codex must not modify files, commit, push, deploy or broaden scope.

## Collect

git status --short
git diff --stat
git diff --check

Do not include secrets, tokens, .env values, credentials or irrelevant logs.

Create .ai/codex/YYYY-MM-DD-<slug>-review-request.md with task, scope, changed files, diff summary and review focus.

Check correctness, regressions, security, performance, maintainability, test coverage, project rules, build or runtime risk and UI risk.

| Severity | File | Issue | Evidence | Suggested Fix |
|---|---|---|---|---|

A finding is actionable only with a concrete path, specific evidence, clear risk and bounded fix.

ein format, das befund und meinung trennt

Jeder Befund enthält Schweregrad, Datei, Problem, Beleg und einen begrenzten Fix. OpenAIs Beitrag zu eigenen Code-Review-Regeln empfiehlt, Review-Erwartungen in Repository-Anweisungen zu kodifizieren. Das schafft wiederholbare Maßstäbe. Der Reviewer soll Defekte priorisieren und Stilhinweise nur nennen, wenn sie Wartbarkeit oder Zuverlässigkeit berühren.

# Codex Review Request

## Phase

REVIEW

## Task

## Scope

## Changed Files

## Diff Summary

## Review Focus

Check correctness, regressions, security, performance, maintainability, tests, type safety, build or runtime risk and AGENTS.md rules.

## Do Not

- modify files
- commit
- push
- deploy
- broaden scope
- refactor
- flag style-only issues
- speculate without code evidence

## Expected Output

| Severity | File | Issue | Evidence | Suggested Fix |
|---|---|---|---|---|

Critical breaks runtime, build, data integrity, security, deployment or public behavior.
Must-fix is a likely in-scope regression. Should-fix is a clear reliability problem.
Optional is useful but not required. Rejected is speculative, unrelated or style-only.

Codex-Befunde verarbeiten

Ein Codex-Befund ist ein Prüfhinweis, noch keine Wahrheit. Claude Code liest ihn, sucht die genannte Stelle und verfolgt den realen Daten- oder Kontrollfluss. Danach wird der Punkt als kritisch, must-fix, should-fix, optional oder abgelehnt klassifiziert.

Abgelehnt werden spekulative Hinweise, Befunde außerhalb des freigegebenen Scopes, bereits bestehende unabhängige Probleme und reine Stilwünsche. Ein breiter Refactor wird nicht aus einem lokalen Review-Hinweis abgeleitet. Akzeptierte Punkte werden mit dem kleinsten tragfähigen Fix umgesetzt und anschließend erneut geprüft.

---
description: Consume a Codex review result, verify findings against the actual code, and convert actionable issues into a minimal fix plan.
---

# Consume Codex Review

1. Read the Codex review.
2. Classify findings: critical, must-fix, should-fix, optional or rejected.
3. Verify each actionable finding against the actual code.
4. Reject speculative or out-of-scope findings.
5. Create a minimal fix plan.
6. Apply only required fixes.
7. Run verification.
8. Update handoff or review status.

Reject unsupported, unrelated, purely stylistic or broad unapproved refactors.

Report accepted and rejected findings, changed files, verification, remaining risks and whether another Codex review is needed.

das Ship Gate

SHIP ist kein Synonym für „Code geschrieben“. Der Gate-Schritt prüft, ob Scope und Arbeitszustand verstanden sind, relevante Checks gelaufen sind und keine ungeklärten Findings übrig bleiben. Bei UI-Änderungen gehört eine Browserprüfung dazu. Bei öffentlichem Text kommt die Inhalts- und Markenprüfung hinzu.

Deployment braucht weiterhin eine ausdrückliche Freigabe. Ein bestandener lokaler Build erteilt sie nicht. Ein offener Lock, ein unklarer Testfehler oder ein kritischer Review-Befund blockiert den Schritt.

---
description: Final release gate before deployment, ship, production update, release switch, or live verification.
---

# Ship Gate

Verify:
1. Scope is clear.
2. No conflicting lock exists in .ai/locks/.
3. No unresolved Codex review exists in .ai/codex/.
4. git status --short is understood.
5. git diff --check passes.
6. Relevant tests, typecheck, lint and build ran or are explicitly unavailable.
7. UI checks ran for UI changes.
8. Brand gates ran for public wording.
9. No secrets are in the diff.
10. No unrelated files changed.
11. User approval exists for deploy.

Return PASS or BLOCKED, evidence, commands, unresolved risks and exact next action.

Hard stop on failed build, unclear test failure, unrelated diff, ambiguous target, active parallel work, missing approval or unresolved critical finding.

ein konservativer Post-Edit-Hook

Hooks sind laut Anthropic deterministische Befehle, die an definierten Punkten im Lebenszyklus von Claude Code laufen. Das macht sie geeignet für kleine, zuverlässige Schutzmaßnahmen. Der Post-Edit-Hook hier zeigt den Arbeitsstatus, prüft gestagte und ungestagte Änderungen mit git diff --check HEAD und meldet Lock-Dateien. Neue unversionierte Dateien erscheinen im Status; ihre Inhalte werden erst geprüft, sobald Git sie verfolgt.

Er startet keine vollständigen Builds und keine Deployments. Solche Aktionen sind langsam, projektabhängig und können Außenwirkung haben. Sie bleiben sichtbare Schritte unter VERIFY und SHIP.

#!/usr/bin/env bash
set -euo pipefail

cd "${CLAUDE_PROJECT_DIR:-.}"

echo "[claude-hook] post-edit check"

if git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
  echo "[claude-hook] changed files:"
  git status --short || true

  echo "[claude-hook] whitespace/conflict-marker check:"
  git diff --check HEAD || {
    echo "[claude-hook] git diff --check HEAD failed"
    exit 2
  }

  if [ -d ".ai/locks" ]; then
    active_locks="$(find .ai/locks -type f -name '*.lock.md' 2>/dev/null || true)"
    if [ -n "$active_locks" ]; then
      echo "[claude-hook] active locks found:"
      echo "$active_locks"
    fi
  fi
fi

Vor der Aktivierung wird das Skript mit bash -n .claude/hooks/post-edit-check.sh geprüft und ausführbar gemacht. Eine Registrierung in .claude/settings.json wird nur ergänzt, wenn die Datei vorhanden ist oder bewusst Teil des Setups werden soll.

Locks und parallele arbeit

Ein Lock ist eine kleine Markdown-Datei wie .ai/locks/billing.lock.md. Darin stehen Scope, Besitzer, Beginn und erwartetes Ende. Das ist keine verteilte Sperre mit Transaktionsgarantie. Es ist ein sichtbarer Vertrag für Agenten und Menschen.

Vor BUILD wird geprüft, ob der eigene Scope frei ist. Vor SHIP wird geprüft, ob eine aktive parallele Arbeit vom Release überschrieben werden könnte. Nach Abschluss wird der Lock kontrolliert entfernt. Codex braucht für ein read-only Review keinen Schreib-Lock, solange es keine Dateien verändert.

ablauf eines echten changes

Ein konkreter Ablauf zeigt, wie wenig neue Logik nötig ist. Angenommen, ein Formular akzeptiert eine ungültige Domain.

1. DEFINE: Der Fehler, der erlaubte Scope und die Akzeptanz werden notiert. Ein gezielter Test muss die ungültige Domain ablehnen und gültige Domains weiter akzeptieren.
2. PLAN: Claude Code verfolgt Eingabe, Validierung und Aufrufer. Es benennt die eine gemeinsame Stelle, den Test und die Risiken.
3. BUILD: Claude Code setzt den kleinsten Fix im reservierten Scope um. Kein benachbarter Refactor wird mitgenommen.
4. VERIFY: Der gezielte Test läuft zuerst. Danach folgen git diff --check, relevante Typprüfung und bei Bedarf der Build.
5. REVIEW: Der interne Diff-Reviewer prüft den Stand. Bei Sicherheits- oder Release-Relevanz entsteht zusätzlich der begrenzte Codex-Request.
6. REVIEW auswerten: Claude Code belegt oder verwirft die Findings. Ein akzeptierter Fix durchläuft VERIFY erneut.
7. SHIP: Status, Checks, Locks, offene Risiken und Nutzerfreigabe werden geprüft. Erst dann darf ein getrennter Release-Ablauf beginnen.

OpenAI beschreibt Remote-Codex-Arbeit als parallelisierbare Engineering-Aufgabe mit klaren Umgebungen und überprüfbaren Ergebnissen. Für diesen lokalen Ablauf wird daraus keine parallele Schreiblogik abgeleitet. Der Nutzen liegt in der unabhängigen Prüfung, während die Schreibhoheit eindeutig bleibt.

was bewusst nicht automatisiert wird

• Keine API-Verkabelung: Es wird weder die OpenAI- noch die Anthropic-API integriert.
• Kein ChatGPT-Handoff: ChatGPT ist weder Runtime-Agent noch Übergabeschicht im Repository.
• Keine automatischen Commits: Ein grüner Check verändert keine Git-Historie ohne Freigabe.
• Keine automatischen Deployments: SHIP prüft die Voraussetzungen, führt aber ohne Zustimmung keinen Release aus.
• Keine Secret-Erfassung: Review-Aufträge enthalten keine Tokens, Zugangsdaten oder .env-Werte.
• Kein Codex-Autofix: Findings werden zuerst am echten Code verifiziert.
• Keine Vollprüfung nach jedem Edit: Der Hook bleibt schnell. Umfangreiche Tests laufen gezielt unter VERIFY.

Diese Grenzen sind kein Mangel an Automatisierung. Sie halten irreversible oder teure Aktionen an einer sichtbaren Entscheidungsstelle.

häufige fragen

Brauche ich für diese Orchestrierung eine API-Integration?

Nein. Der beschriebene Ablauf arbeitet mit Repository-Regeln, Skills, Review-Dateien und den vorhandenen Werkzeugen. Es wird weder eine OpenAI- noch eine Anthropic-API eingebaut.

Ist Codex von sich aus immer read-only?

Nein. Read-only ist in diesem Betriebsmodell eine bewusst gesetzte Repository-Regel. Sie macht Codex zum unabhängigen Reviewer. Ein isolierter Implementierungsauftrag wäre nur nach ausdrücklicher Freigabe vorgesehen.

Warum schreibt nur Claude Code?

Ein aktiver Schreiber pro Scope verhindert widersprüchliche Änderungen und unklare Zuständigkeit. Claude Code führt den bestehenden Ablauf aus. Codex beurteilt den Diff unabhängig und liefert belegte Befunde.

Muss jeder kleine Diff durch Codex geprüft werden?

Nein. Ein unabhängiges Review lohnt sich bei riskanten, breiten, releasekritischen, sicherheitsrelevanten oder ausdrücklich angeforderten Änderungen. Triviale, lokal geprüfte Korrekturen brauchen keinen zweiten Prüfweg.

Darf Claude Code Codex-Befunde automatisch übernehmen?

Nein. Claude Code prüft jeden Befund am tatsächlichen Code. Spekulative, fachfremde, rein stilistische oder bereits vorher bestehende Punkte werden verworfen.

Welche Aufgabe haben Locks?

Locks markieren einen aktuell bearbeiteten Scope. Sie verhindern nicht technisch jede Kollision, machen parallele Zuständigkeiten aber vor dem nächsten Schreibzugriff sichtbar und bilden am Ship Gate einen klaren Stop-Grund.

Was prüft der konservative Post-Edit-Hook?

Er zeigt geänderte Dateien, führt git diff --check HEAD aus und meldet vorhandene Lock-Dateien. Builds, Tests, Commits und Deployments bleiben bewusste Schritte im Master-Loop.

quellen und stand

Stand: 23.09.2026. Produktfunktionen und Dokumentation können sich ändern. Read-only ist in diesem Beitrag eine bewusst gesetzte Arbeitsregel für Codex, keine unbelegte Aussage über dessen Produktdefault.

• Anthropic: Claude Code features overview
• Anthropic: Subagents
• Anthropic: Skills
• Anthropic: Hooks guide
• OpenAI: Custom code review rules for Codex
• OpenAI: Mastering Codex remote for engineering
• OpenAI: Codex mit AGENTS.md anleiten