Coding-Agent

Coding Agent

Verwenden für Hintergrund-Feature-Builds, PR-Reviews, große Refactorings und Issue-to-PR-Schleifen. Nicht verwenden für einfache Bearbeitungen, schreibgeschützte Abfragen, ACP-Thread-gebundene Arbeiten oder innerhalb von ~/.openclaw, $OPENCLAW_STATE_DIR oder aktiven OpenClaw-Statusverzeichnissen.

Harte Regeln

• Immer mit background:true starten.
• Codex und OpenCode: pty:true verwenden.
• Codex: Niemals das umgebende CODEX_HOME oder das standardmäßige ~/.codex übernehmen. Verwenden Sie ein separat authentifiziertes Coding-Agent-Home und beschränken Sie es auf jeden Codex-Befehl.
• Claude Code: kein PTY; claude --permission-mode bypassPermissions --print verwenden.
• Vor dem Start eine echte Benachrichtigungsroute erfassen.
• Der Worker muss den Abschluss/Misserfolg über openclaw message send senden.
• Nicht auf Heartbeat, Systemereignisse oder notify-on-exit verlassen.
• Mit process überwachen; langsame Arbeiter nicht ohne Grund beenden.
• Wenn der Benutzer nach einem bestimmten Agenten gefragt hat, diesen Agenten verwenden.
• Wenn der Worker fehlschlägt/hängt, neu starten oder nachfragen; nicht stillschweigend per Hand codieren.
• Niemals Branches auschecken oder Hintergrund-Coding-Agents in ~/Projects/openclaw ausführen; einen isolierten Checkout verwenden.
• Den Quell-Ref als vertrauenswürdig oder nicht vertrauenswürdig einstufen, bevor ein Checkout oder Worktree erstellt wird. Niemals einen beitragendengesteuerten Ref außerhalb des genehmigten Sandbox/Review-Workflows für nicht vertrauenswürdige PRs des Repositorys materialisieren und niemals einen Worker mit umgangenen Berechtigungen darin starten.
• Für Aufgaben, die ein Git-unterstütztes Projekt ändern, das Git-Worktree vor dem Start vorbereiten und überprüfen und dann den genauen, unten stehenden Git-Vorbereitungsblock in den Worker-Prompt einfügen.

Verbindliche Git-Vorbereitung

Vor dem Start von Codex, Claude Code oder OpenCode für Arbeiten, die ein Git-unterstütztes Projekt ändern:

1. Das beabsichtigte Ziel-Repository festlegen, dann das kanonische Remote auswählen. Bevorzugen Sie upstream, wenn es existiert und mit diesem Ziel übereinstimmt; andernfalls origin überprüfen. Den Standard-Branch des ausgewählten kanonischen Remotes dynamisch auflösen. Den Ziel-Base-Branch aus einem expliziten Aufgaben-Branch oder autoritativen vorhandenen PR-Metadaten bestimmen; für andere geteilte Branches den konfigurierten/verfolgten Base beweisen oder nachfragen. Nur für neue Arbeiten ohne anderen angegebenen Base den kanonischen Standard verwenden. Stoppen, wenn das Repository, das Remote oder der Ziel-Base-Branch nicht nachgewiesen werden können.
2. Den Quell-Ref vor jedem Checkout oder jeder Worktree-Erstellung als vertrauenswürdig oder nicht vertrauenswürdig einstufen. Für beitragendengesteuerte Refs den genehmigten Sandbox/Review-Workflow für nicht vertrauenswürdige PRs des Repositorys verwenden, der die Materialisierung des Refs innerhalb des Sandbox besitzen muss, oder stoppen. Die verbleibenden Schritte und Startformulare sind nur für vertrauenswürdige Refs vorgesehen.
3. Für vertrauenswürdige neue Arbeiten unmittelbar vor der Erstellung eines neuen isolierten Worktrees und Branches von <canonical>/<targetBaseBranch> git fetch --prune <canonical> ausführen.
4. Für vertrauenswürdige neue Arbeiten überprüfen, ob der anfängliche HEAD des Worktrees der abgerufenen Ziel-Base-SHA entspricht. Das kanonische Remote, den kanonischen Standard-Branch, den Ziel-Base-Branch, die Base-SHA, den Worktree-Pfad und den Branch aufzeichnen.
5. Für einen vertrauenswürdigen vorhandenen PR oder geteilten Branch das kanonische Ziel-Base und den Quell-Branch unmittelbar vor der Erstellung eines isolierten Worktrees aus dem abgerufenen Quell-Branch abrufen. Diesen Quell-Ref und die Start-SHA aufzeichnen, seine Abweichung vom aktualisierten Ziel-Base melden und nicht automatisch rebasen, zusammenführen, zurücksetzen, force-pushen oder anderweitig die gemeinsame Geschichte umschreiben.
6. Den Worker im isolierten Worktree starten, niemals im primären Checkout. Für OpenClaw bleibt der primäre Checkout unter ~/Projects/openclaw verboten.

Für Aufgaben, die ein Git-unterstütztes Projekt ändern, diesen Block mit echten Werten an den Worker-Prompt anhängen:

Git-Vorbereitung (verbindlich vor Bearbeitungen):
- kanonisches Remote: <canonicalRemote>
- kanonischer Standard-Branch: <canonicalDefaultBranch>
- Ziel-Base-Branch: <targetBaseBranch>
- abgerufene Ziel-Base-SHA: <targetBaseSha>
- Vorbereitungsmodus: <neue Arbeit | vorhandener PR/geteilter Branch>
- Checkout-Vertrauenswürdigkeit: vertrauenswürdig
- vorbereiteter Quell-Ref: <canonicalRemote/targetBaseBranch | abgerufener vertrauenswürdiger Quell-Ref>
- vorbereitete Start-SHA: <preparedStartSha>
- isoliertes Worktree: <worktreePath>
- Arbeits-Branch: <branch>
- Vorbereitungsbeleg: <neue Arbeit: `git fetch --prune <canonicalRemote>` lief unmittelbar vor Erstellung von `<canonicalRemote>/<targetBaseBranch>` | vorhandener Branch: das kanonische Ziel-Base und der vertrauenswürdige Quell-Ref wurden unmittelbar vor der Erstellung des Worktrees von `<preparedSourceRef>` bei `<preparedStartSha>` abgerufen>

Vor der Bearbeitung überprüfen, ob das aktuelle Verzeichnis das isolierte Worktree ist und sein anfänglicher HEAD gleich <preparedStartSha> ist. Für neue Arbeiten muss diese SHA gleich <targetBaseSha> sein. Niemals den primären Checkout bearbeiten. Für vorhandene PR/geteilter-Branch-Arbeiten die Abweichung melden und nicht rebasen, zusammenführen, zurücksetzen, force-pushen oder anderweitig die gemeinsame Geschichte umschreiben, es sei denn, es wird explizit darum gebeten.
Unmittelbar vor dem finalen Push oder PR für neu verfasste Arbeiten `git fetch --prune <canonicalRemote>` und `git merge-base --is-ancestor <canonicalRemote>/<targetBaseBranch> HEAD` ausführen. Wenn die Abstammungsprüfung fehlschlägt, den neuen Branch auf die neueste Ziel-Base aktualisieren, den relevanten Beweis erneut durchführen und nur dann ohne Force pushen. Für vorhandene PR/geteilter-Branch-Arbeiten eine fehlgeschlagene Abstammungsprüfung melden und dem Repository-Workflow folgen, ohne den Branch umzuschreiben.

Für vertrauenswürdige Refs muss der Starter das Worktree erstellen und überprüfen, bevor der Bearbeitungs-Worker gestartet wird; delegieren Sie die Worktree-Erstellung nicht an diesen Worker. Der genehmigte Workflow für nicht vertrauenswürdige PRs muss stattdessen den Checkout und die Worktree-Materialisierung innerhalb seines Sandbox besitzen. Niemals einen Worker in ~/Projects/openclaw starten. Schreibgeschützte Aufgaben und projektfremde Spielereien erfordern den Git-Vorbereitungsblock nicht.

Benachrichtigungsblock

Fügen Sie diese Form mit echten Werten an jeden Worker-Prompt an:

Benachrichtigungsroute:
- Kanal: <notifyChannel>
- Ziel: <notifyTarget>
- Konto: <notifyAccount oder weglassen>
- reply_to: <notifyReplyTo oder weglassen>
- thread_id: <notifyThreadId oder weglassen>

Wenn fertig, genau eine Abschluss- oder Fehlermeldung senden mit:
openclaw message send --channel <channel> --target '<target>' --message '<kurzes Ergebnis>'
--account, --reply-to oder --thread-id nur hinzufügen, wenn oben vorhanden.
openclaw system event oder heartbeat nicht verwenden.

Wenn keine vertrauenswürdige Route existiert, mitteilen, dass die Abschluss-Benachrichtigung nicht verfügbar ist.

Startformulare

Schreiben Sie den Worker-Prompt zuerst in eine temporäre Datei. Dies vermeidet Shell-Quoting-Probleme, wenn der erforderliche Benachrichtigungsblock Anführungszeichen oder Zeilenumbrüche enthält.

PROMPT=$(mktemp -t openclaw-worker-prompt.XXXXXX)
cat >"$PROMPT" <<'EOF'
Aufgabe.
<Verbindlicher Git-Vorbereitungsblock>
<Benachrichtigungsblock>
EOF
printf 'Prompt-Datei: %s\n' "$PROMPT"

Verwenden Sie $PROMPT beim Start aus derselben Shell/Sitzung. Wenn Sie einen separaten Tool-Aufruf verwenden, ersetzen Sie den gedruckten Pfad. Die Startformulare unten sind nur für vertrauenswürdige Checkouts; nicht vertrauenswürdige beitragendengesteuerte Refs erfordern den genehmigten Sandbox/Review-Workflow des Repositorys.

Bereiten Sie vor dem ersten Codex-Worker auf einem Host ein dediziertes Auth-Home im Vordergrund vor. Kopieren Sie keine auth.json oder andere Anmeldeinformationen aus dem umgebenden ~/.codex; autorisieren Sie dieses Home separat. Codex beschränkt sowohl Datei- als auch Schlüsselbund-Anmeldeinformationen durch CODEX_HOME.

CODEX_WORKER_HOME="$HOME/.codex-coding-agent"
mkdir -p "$CODEX_WORKER_HOME"
if ! env -u CODEX_API_KEY -u CODEX_ACCESS_TOKEN -u OPENAI_API_KEY \
  CODEX_HOME="$CODEX_WORKER_HOME" codex login status >/dev/null 2>&1; then
  printf 'Codex-Coding-Agent-Login erforderlich für %s\n' "$CODEX_WORKER_HOME"
  env -u CODEX_API_KEY -u CODEX_ACCESS_TOKEN -u OPENAI_API_KEY \
    CODEX_HOME="$CODEX_WORKER_HOME" codex login --device-auth
fi
printf 'Codex-Worker-Home: %s\n' "$CODEX_WORKER_HOME"

Der Login ist ein interaktiver Einrichtungsschritt im Vordergrund, kein Hintergrund-Worker. Der Startbefehl wiederholt das festgelegte, in Anführungszeichen gesetzte Home und entfernt umgebende Codex- und OpenAI-Auth-Überschreibungen. Exportieren Sie das Worker-Home niemals in die OpenClaw-Gateway-Umgebung.

Codex:

bash pty:true background:true workdir:/pfad/zu/isolated-worktree command:"env -u CODEX_API_KEY -u CODEX_ACCESS_TOKEN -u OPENAI_API_KEY CODEX_HOME=\\