Codex, Claude Code und Cursor als ein CLI-Team nutzen

Codex, Claude Code und Cursor können Repositorys bearbeiten, Befehle ausführen und Projektanweisungen befolgen, soweit ihre Konfiguration und Berechtigungen dies zulassen. Dieser Artikel erprobt einen dateibasierten Arbeitsvertrag. Er behauptet weder, dass jedes Team drei Agenten braucht, noch dass der Vertrag toolspezifisches Verhalten beseitigt.

Dieser Artikel zeigt, wie das mit vorhandenen Dateien und CLIs funktioniert:

• Gemeinsame Projektanweisungen in AGENTS.md
• Eine Brücke zu Claude über CLAUDE.md, die @AGENTS.md importiert
• Grundlegende Cursor-Anweisungen und optionale .cursor/rules
• Strukturiertes Übergabe-Markdown zwischen den Rollen
• Nicht interaktive CLI-Läufe für Entwurf, Prüfung und Implementierung

Dafür ist keine eigene Projektmanagementplattform erforderlich. Wenn Sie später einen gemeinsamen Aufgabenbestand für mehrere Agenten benötigen, ergänzen Sie Linear Multi-Agent-Projektmanagement. Hier dienen Git und Markdown als Koordinationsmedium.

Die Produktdokumentation wurde am 2026-08-04 erneut anhand von AGENTS.md, den OpenAI-Codex-Hinweisen zu AGENTS.md, dem nicht interaktiven Codex-Modus, der Claude-Code-Dokumentation zu Memory, der Claude-Code-CLI-Referenz und der Cursor-CLI-Dokumentation geprüft. Die vollständige Übergabe zwischen den drei Clients wurde bei dieser Prüfung nicht durchgehend ausgeführt. Prüfen Sie Befehle und Berechtigungen mit festgelegten Client-Versionen, bevor Sie sich auf den Workflow verlassen.

Die Teamstruktur

Eine verlässliche Spezialisierung für den Einstieg:

Diese Rollen sind Konventionen, keine Einschränkungen der Anbieter. Jedes Tool kann entwerfen, prüfen oder implementieren. Die Spezialisierung schafft eine klare Grenze zwischen den Artefakten: Ein Agent schreibt den Plan, ein anderer prüft ihn kritisch, und ein dritter implementiert nur das, was diese Prüfung bestanden hat.

Gemeinsame Anweisungen aus einer maßgeblichen Quelle

Verwenden Sie AGENTS.md als portable Grundlage

AGENTS.md ist das toolübergreifende Anweisungsformat unter der Agentic AI Foundation. Codex liest es nativ. Cursor unterstützt eine AGENTS.md im Stammverzeichnis als gemeinsame Projektanweisung neben .cursor/rules. Halten Sie die Datei kurz und handlungsorientiert:

# AGENTS.md

## Commands
- Install: `pnpm install`
- Test: `pnpm test`
- Typecheck: `pnpm typecheck`
- Lint: `pnpm lint`

## Patch rules
- One behavior change per branch
- Prefer existing helpers over new dependencies
- Do not edit secrets or `.env*` files
- Do not merge to main

## Multi-agent protocol
- Read `docs/handoffs/` before starting
- Write status back into the active handoff file
- Designer, reviewer, and implementer must be different runs
- Stop for auth, payments, production infra, or data deletion

Die Codex-Dokumentation von OpenAI beschreibt die Suche vom Projektstamm bis zum Arbeitsverzeichnis. Näher gelegene Dateien haben Vorrang; optional gibt es AGENTS.override.md. Die zusammengeführte Standardgröße ist auf 32 KiB begrenzt, sofern sie nicht erhöht wird. Halten Sie die Datei im Stammverzeichnis knapp und legen Sie paketspezifische Regeln in verschachtelten AGENTS.md-Dateien ab.

Binden Sie Claude Code über CLAUDE.md ein

Claude Code liest CLAUDE.md, nicht AGENTS.md. Die offizielle Empfehlung lautet, die gemeinsame Datei zu importieren:

@AGENTS.md

## Claude Code
- Prefer plan mode before edits on `src/billing/` and auth code
- For review jobs, do not implement unless the handoff status is `implement` or `fixes`

Ein symbolischer Link (ln -s AGENTS.md CLAUDE.md) funktioniert ebenfalls, wenn Sie keine Claude-spezifischen Ergänzungen benötigen. Unter Windows ist der Import über @AGENTS.md vorzuziehen.

Bestätigen Sie das Laden mit Claudes /context und prüfen Sie Memory files.

Halten Sie Cursor-spezifische Regeln knapp

Cursor kann die AGENTS.md im Stammverzeichnis für gemeinsame Konventionen verwenden. Nutzen Sie .cursor/rules/*.mdc nur für Cursor-spezifische Anforderungen, etwa Regeln für bestimmte Dateimuster. Pflegen Sie keine drei voneinander abweichenden Regelwerke.

Die Übergabedatei ersetzt das Gespräch unter Teammitgliedern

Erstellen Sie ein Verzeichnis:

mkdir -p docs/handoffs

Verwenden Sie je Arbeitseinheit eine Datei:

docs/handoffs/2026-07-29-pricing-section.md

# Handoff: pricing section

- ID: pricing-section
- Status: design
- Owner now: codex
- Next owner: claude
- Branch: codex/design-pricing-section
- Worktree: ../app-pricing-section

## Goal
Implement the marketing pricing section using existing Section/PlanCard patterns.

## Non-goals
Billing, coupons, seat math.

## Design
(Codex fills this)

## Review
(Claude fills this)

## Implementation notes
(Cursor fills this)

## Verification
- Command: `pnpm test:e2e --grep "pricing"`
- Last result:

## Decision log
- 2026-07-29 Codex: drafted component boundaries

Geeignete Statuswerte bilden Schleifen ab, nicht nur eine Einbahnstraße:

1. design
2. design-review: Blockierende Befunde führen zurück zu design; eine Prüfung ohne blockierende Befunde führt zu implement
3. implement
4. impl-review: Blockierende Befunde führen zu fixes; eine Prüfung ohne blockierende Befunde setzt done
5. fixes: Die implementierende Rolle behebt die Befunde und kehrt anschließend zu impl-review zurück
6. done
7. blocked-human

Nicht jede Aufgabe durchläuft fixes. Eine saubere Prüfung unter impl-review kann direkt zu done führen.

Jeder CLI-Lauf beginnt mit dem Lesen der Datei und endet mit der Aktualisierung von Status, zuständiger Rolle und Entscheidungsprotokoll. Mehr Orchestrierung ist hier nicht nötig.

Beispiel nach einem Zyklus aus Entwurf und Prüfung

Beispielhafter Auszug aus der Übergabedatei, nachdem Codex entworfen und Claude geprüft hat:

- Status: implement
- Owner now: cursor
- Next owner: claude

## Design
Files: `PricingSection.tsx` (new), reuse `PlanCard.tsx`
CTA must track clicks with `trackEvent()` + `getCtaClickProps()` from `src/lib/analytics.ts`
Mobile: stacked below `md`, three columns from `md` up
Plan IDs: `starter`, `pro`, `business`
Test: `pnpm test:e2e --grep "pricing"`

## Review
Blocking: none remaining (breakpoint + plan IDs resolved in Design above)
Non-blocking:
- Extract plan constants later if CMS arrives.

## Decision log
- 2026-07-29 Codex: initial component boundaries
- 2026-07-29 Claude: requested breakpoint + explicit plan IDs
- 2026-07-29 Codex: updated Design; Claude cleared blocking items → implement

Cursor soll genau diesem Artefakt folgen. Der Chatverlauf ist optional, die Datei verpflichtend.

Die einzelnen CLIs installieren und aufrufen

Die genauen Installationswege ändern sich. Verwenden Sie deshalb die aktuelle Installationsdokumentation des jeweiligen Anbieters. Entscheidend ist das Muster für nicht interaktive Aufrufe.

Codex: Entwurfsdurchlauf

Der nicht interaktive Codex-Modus ist codex exec. Standardmäßig läuft er in einer schreibgeschützten Sandbox. Ein Entwurfsauftrag, der die Übergabedatei aktualisiert, benötigt Schreibrechte für den Workspace:

cd ../app-pricing-section
codex exec --sandbox workspace-write "$(cat <<'EOF'
Read AGENTS.md and docs/handoffs/2026-07-29-pricing-section.md.
Status is design. Produce the Design section only:
- proposed files
- component/API boundaries
- test plan
- risks
- open questions
Do not implement application code.
Set status to design-review and next owner to claude.
Append a Decision log entry.
EOF
)"

Verwenden Sie das interaktive codex nur, wenn Sie den Entwurf live steuern möchten. Für Skripte und aufeinanderfolgende Läufe ist codex exec vorzuziehen.

Claude Code: Prüfdurchlauf

Der Print-Modus von Claude Code kann die Übergabedatei prüfen und aktualisieren, aber nur, wenn Ihre Berechtigungseinstellungen Schreibzugriffe in diesem Worktree zulassen. Begrenzen Sie den Umfang klar:

cd ../app-pricing-section
claude -p --permission-mode acceptEdits --max-turns 30 --max-budget-usd 5 --output-format text "$(cat <<'EOF'
Read AGENTS.md / CLAUDE.md and docs/handoffs/2026-07-29-pricing-section.md.
You are the reviewer. Do not implement application code.
Challenge the Design section for missing edge cases, local-architecture mismatches, weak tests, and security issues.
Write findings into the Review section as Blocking vs Non-blocking.
If blocking findings exist, set status to design and next owner to codex.
Otherwise set status to implement and next owner to cursor.
Append a Decision log entry.
EOF
)"

Wenn der Berechtigungsmodus von Claude im nicht interaktiven Betrieb keine Dateien schreiben darf, führen Sie die Prüfung schreibgeschützt aus und lassen Sie einen Menschen oder ein Skript den Abschnitt „Review“ in die Übergabedatei einfügen. Verwenden Sie für Aktualisierungen der Übergabedatei in einem kurzlebigen Worktree vorzugsweise --permission-mode acceptEdits oder eine Positivliste in den Einstellungen. Nutzen Sie --dangerously-skip-permissions nicht in einem realen Checkout.

Nützliche Claude-Code-Optionen für skriptgesteuerte Läufe finden Sie in der CLI-Referenz:

• -p / --print für einen nicht interaktiven Abschluss
• --max-turns zum Begrenzen von Schleifen
• --max-budget-usd zum Begrenzen der Ausgaben
• --output-format json|text|stream-json für die Automatisierung
• --permission-mode acceptEdits, wenn die Prüfung die Übergabedatei in einem klar begrenzten Worktree schreiben muss

Verwenden Sie --dangerously-skip-permissions nicht unbedacht in produktiven Checkouts.

Cursor: Implementierungsdurchlauf

Verwenden Sie für die Cursor CLI (agent) denselben dedizierten Worktree, der in der Übergabedatei steht. Implementieren Sie nicht aus dem Haupt-Checkout:

cd ../app-pricing-section
agent -p --trust --sandbox enabled --output-format text "$(cat <<'EOF'
Read AGENTS.md and docs/handoffs/2026-07-29-pricing-section.md.
Status must be implement or fixes.
Implement only the approved Design, respecting Review blocking resolutions.
Keep the patch small. Add or update tests from the Verification section.
Run the verification command and record the result in the handoff file.
Set status to impl-review and next owner to claude.
Do not merge.
EOF
)"

Wichtige Optionen der Cursor CLI:

• -p / --print: nicht interaktiv; hat bereits Zugriff auf Schreib- und Shell-Tools
• --force / --yolo: bestätigt Shell-Befehle automatisch, sofern sie nicht ausdrücklich verweigert wurden; nur in kurzlebigen Sandboxes verwenden, nicht als Standard beim Schreiben von Code
• --sandbox enabled|disabled: Sandbox-Modus für den Lauf; enabled ist beim Implementieren mit --trust vorzuziehen
• --trust: vertraut dem Workspace in der Automatisierung
• -w / --worktree [name]: isolierter Checkout unter ~/.cursor/worktrees/<repo>/ mit einem anderen Pfad als bei einem manuellen git worktree add; aktualisieren Sie bei Verwendung die Felder für Branch und Worktree in der Übergabedatei
• --mode plan oder --mode ask: Planungs- beziehungsweise schreibgeschützter Modus
• --output-format text|json|stream-json

Verwenden Sie für reine Cursor-Prüfläufe vorzugsweise die Modi „ask“ oder „plan“ oder eine ausdrückliche Anweisung, nichts zu bearbeiten. Ein manuelles git worktree add sorgt dafür, dass der Pfad in der Übergabedatei dem Checkout der implementierenden Rolle entspricht.

Weitere Hinweise für skriptgesteuerte Workflows bietet Cursors Dokumentation zur Headless CLI.

Übersicht der Anweisungsdateien ohne doppelte Wahrheiten

Wenn eine Regel für alle Agenten gilt, pflegen Sie eine kanonische portable Fassung und nutzen nur die Brücken, die das jeweilige Tool benötigt. Toolspezifische Regeln bleiben lokal. Doppelte Richtlinien schaffen mehrere Aktualisierungspunkte und erhöhen das Risiko, dass sie auseinanderlaufen. Ein Test sollte prüfen, ob jedes Tool das vorgesehene Regelwerk lädt.

Beispiel für die vollständige Pipeline

Ausgangspunkt ist ein sauberes Repository und eine noch nicht implementierte Funktion.

1. Isolierten Worktree erstellen

git fetch origin main
git worktree add -b feat/pricing-section ../app-pricing-section origin/main
cd ../app-pricing-section
mkdir -p docs/handoffs

Füllen Sie die Übergabedatei zunächst mit Ziel, Nichtzielen und Verifikation. Committen Sie dieses Grundgerüst, wenn Ihr Team den Vertrag in PRs sichtbar machen möchte.

2. Codex entwirft

Codex schreibt den Abschnitt „Design“ mit Dateien, Schnittstellen, Tests und Risiken. Der Status wechselt zu design-review.

Ein tatsächlicher Entwurf sollte dieser Form folgen:

## Design
Files:
- `src/components/marketing/PricingSection.tsx` (new)
- `src/components/marketing/PlanCard.tsx` (reuse)
- `tests/e2e/marketing-pricing.spec.ts` (new)

Boundaries:
- PricingSection owns layout and plan list
- PlanCard remains presentational
- CTA links use existing `trackEvent()` + `getCtaClickProps()` helpers

Test plan:
- three plans visible
- CTA hrefs resolve
- analytics helper called once per click

Risks:
- hardcoding plan IDs out of sync with CMS

3. Claude prüft das Design

Der Prüf-Prompt verlangt blockierende und nicht blockierende Befunde. Dadurch gehen unklare Entwürfe zur Überarbeitung zurück. Beispiel:

Blocking:
1. Keine Entscheidung zum mobilen Layout der gestapelten Plankarten.
2. Im Entwurf fehlt der Verifikationsbefehl (unter Design und Verification ergänzen).
Non-blocking:
- Erwägen Sie, die Plandaten in eine Konstante auszulagern.

Der Status kehrt zu design zurück oder wechselt erst zu implement, nachdem alle blockierenden Punkte im Entwurf gelöst wurden.

4. Cursor implementiert

Cursor implementiert ausschließlich den freigegebenen Entwurf und führt Folgendes aus:

pnpm test:e2e --grep "pricing"

Cursor dokumentiert das Ergebnis, öffnet einen PR oder bereitet ihn vor und setzt den Status auf impl-review.

5. Claude prüft die Implementierung

Ein zweiter Claude-Lauf prüft den Diff anhand der Übergabe, nicht anhand eines neu erfundenen Ideals. Blockierende Befunde setzen den Status auf fixes und die zuständige Rolle auf cursor. Eine saubere Prüfung setzt für den anschließenden menschlichen Merge den Status done.

6. Ein Mensch führt den Merge aus

Geschützte Branches bleiben in menschlicher Verantwortung. Agenten können schnell arbeiten, sollten aber nicht die Rolle des Release-Managers übernehmen.

Shell-Orchestrierung ohne Plattform

Ein einfacher Ablaufsteuerer genügt:

#!/usr/bin/env bash
set -euo pipefail
ROOT="${1:?worktree path}"
HANDOFF="${2:?handoff file}"
cd "$ROOT"

status() {
  # Prefer the metadata Status field near the top of the handoff file.
  awk '/^- Status:/{print $3; exit}' "$HANDOFF"
}

case "$(status)" in
  design)
    codex exec --sandbox workspace-write "Read AGENTS.md and $HANDOFF. Fill Design only, then set status=design-review and next owner=claude. Do not implement application code."
    ;;
  design-review|impl-review)
    claude -p --permission-mode acceptEdits --max-turns 30 --max-budget-usd 5 --output-format text "Review $HANDOFF per AGENTS.md. Update Review + status only. Do not implement application code."
    ;;
  implement|fixes)
    agent -p --trust --sandbox enabled --output-format text "Status must be implement or fixes. Implement or fix per $HANDOFF and AGENTS.md. Update handoff. Do not merge."
    ;;
  done|blocked-human)
    echo "No agent action for $(status)"
    ;;
  *)
    echo "Unknown status in $HANDOFF" >&2
    exit 1
    ;;
esac

Das ist bewusst unspektakulär. Eine einfache Orchestrierung lässt sich leichter untersuchen. Begrenzen Sie Sandboxes und Berechtigungsmodi so stark, wie es die jeweilige Phase erlaubt. Entwurf und Prüfung benötigen keinen umfassenden Systemzugriff.

Fehlermuster

Nicht interaktive Optionen, die Bearbeitungen oder Berechtigungen automatisch genehmigen, sind Hilfsmittel für Sandboxes und klar begrenzte Worktrees. Sie sind kein Zugriffskontrollmodell für den Produktivbetrieb.

Was Sie noch nicht automatisieren sollten

• Merges in geschützte Branches
• Produktiv-Deployments
• Rotation von Secrets
• Schemamigrationen ohne einen von Menschen geprüften Plan
• Workflows, bei denen die Übergabedatei selbst ungeprüft aus einer nicht vertrauenswürdigen externen Quelle stammt

Praktische Grundausstattung

1. Eine AGENTS.md im Stammverzeichnis mit Befehlen, Patch-Regeln und Multi-Agent-Protokoll hinzufügen.
2. CLAUDE.md mit @AGENTS.md hinzufügen.
3. docs/handoffs/_template.md hinzufügen.
4. Eine kleine Funktion auswählen.
5. Entwurf → Prüfung → Implementierung → Prüfung einmal von Hand durchlaufen.
6. Erst danach die Statuswerte in einem Shell-Ablaufsteuerer abbilden.

Wenn dieselben Agenten Aufgaben aus einem gemeinsamen Unternehmens-Backlog übernehmen sollen, ergänzen Sie Linear MCP und das Modell für Beanspruchungs- und Prüfstatus aus Linear Multi-Agent-Projektmanagement. Die Markdown-Übergabe bleibt als technisches Notizbuch je Issue nützlich.

Der Standard ist der Vertrag

Codex, Claude Code und Cursor überschneiden sich bereits bei ihren Fähigkeiten. Sie werden zu einem Team, wenn Sie nicht nur abstrakt „Zusammenarbeit“ verlangen, sondern einen sichtbaren Vertrag durchsetzen:

• gemeinsame Anweisungen
• ausdrückliche Rolle je Lauf
• Übergabe-Markdown mit Status
• isolierte Worktrees
• begrenzte CLI-Aufrufe
• menschliche Verantwortung für Merge und Release

Das genügt, um mit heutigen Tools ein ernsthaftes lokales Agententeam zu betreiben und schnell zu erkennen, ob das Team improvisiert, statt systematisch zu entwickeln.