openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(i18n): refresh de translations

Browse Source
This commit is contained in:
openclaw-docs-i18n[bot] 2026-04-23 15:00:21 +00:00
parent 7fec945f46
commit fdce0bc61d
6 changed files with 1145 additions and 1194 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

157
docs/de/channels/matrix-push-rules.md Normal file
View File

@ -0,0 +1,157 @@
---
read_when:
- Einrichten von leisem Matrix-Streaming für selbstgehostetes Synapse oder Tuwunel
- Benutzer möchten Benachrichtigungen nur bei abgeschlossenen Blöcken, nicht bei jeder Vorschau-Bearbeitung
summary: Matrix-Push-Regeln pro Empfänger für leise finalisierte Vorschau-Bearbeitungen
title: Matrix-Push-Regeln für leise Vorschauen
x-i18n:
generated_at: "2026-04-23T14:55:30Z"
model: gpt-5.4
provider: openai
source_hash: dbfdf2552ca352858d4e8d03a2a0f5f3b420d33b01063c111c0335c0229f0534
source_path: channels/matrix-push-rules.md
workflow: 15
---
# Matrix-Push-Regeln für leise Vorschauen
Wenn `channels.matrix.streaming` auf `"quiet"` gesetzt ist, bearbeitet OpenClaw ein einzelnes Vorschau-Ereignis direkt vor Ort und markiert die finalisierte Bearbeitung mit einem benutzerdefinierten Content-Flag. Matrix-Clients benachrichtigen nur bei der finalen Bearbeitung, wenn eine Push-Regel pro Benutzer zu diesem Flag passt. Diese Seite richtet sich an Betreiber, die Matrix selbst hosten und diese Regel für jedes Empfängerkonto installieren möchten.
Wenn Sie nur das standardmäßige Matrix-Benachrichtigungsverhalten möchten, verwenden Sie `streaming: "partial"` oder lassen Sie Streaming deaktiviert. Siehe [Einrichtung des Matrix-Kanals](/de/channels/matrix#streaming-previews).
## Voraussetzungen
- Empfängerbenutzer = die Person, die die Benachrichtigung erhalten soll
- Bot-Benutzer = das OpenClaw-Matrix-Konto, das die Antwort sendet
- verwenden Sie für die folgenden API-Aufrufe das Zugriffstoken des Empfängerbenutzers
- gleichen Sie `sender` in der Push-Regel mit der vollständigen MXID des Bot-Benutzers ab
- das Empfängerkonto muss bereits funktionierende Pusher haben — Regeln für leise Vorschauen funktionieren nur, wenn die normale Matrix-Push-Zustellung fehlerfrei funktioniert
## Schritte
<Steps>
<Step title="Leise Vorschauen konfigurieren">
```json5
{
channels: {
matrix: {
streaming: "quiet",
},
},
}
```
</Step>
<Step title="Das Zugriffstoken des Empfängers abrufen">
Verwenden Sie nach Möglichkeit ein vorhandenes Client-Sitzungstoken erneut. Um ein neues zu erstellen:
```bash
curl -sS -X POST \
"https://matrix.example.org/_matrix/client/v3/login" \
-H "Content-Type: application/json" \
--data '{
"type": "m.login.password",
"identifier": { "type": "m.id.user", "user": "@alice:example.org" },
"password": "REDACTED"
}'
```
</Step>
<Step title="Prüfen, ob Pusher vorhanden sind">
```bash
curl -sS \
-H "Authorization: Bearer $USER_ACCESS_TOKEN" \
"https://matrix.example.org/_matrix/client/v3/pushers"
```
Wenn keine Pusher zurückgegeben werden, beheben Sie zuerst die normale Matrix-Push-Zustellung für dieses Konto, bevor Sie fortfahren.
</Step>
<Step title="Die Override-Push-Regel installieren">
OpenClaw markiert finalisierte rein textbasierte Vorschau-Bearbeitungen mit `content["com.openclaw.finalized_preview"] = true`. Installieren Sie eine Regel, die auf diesen Marker plus die Bot-MXID als Absender passt:
```bash
curl -sS -X PUT \
"https://matrix.example.org/_matrix/client/v3/pushrules/global/override/openclaw-finalized-preview-botname" \
-H "Authorization: Bearer $USER_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
--data '{
"conditions": [
{ "kind": "event_match", "key": "type", "pattern": "m.room.message" },
{
"kind": "event_property_is",
"key": "content.m\\.relates_to.rel_type",
"value": "m.replace"
},
{
"kind": "event_property_is",
"key": "content.com\\.openclaw\\.finalized_preview",
"value": true
},
{ "kind": "event_match", "key": "sender", "pattern": "@bot:example.org" }
],
"actions": [
"notify",
{ "set_tweak": "sound", "value": "default" },
{ "set_tweak": "highlight", "value": false }
]
}'
```
Ersetzen Sie vor dem Ausführen Folgendes:
- `https://matrix.example.org`: die Basis-URL Ihres Homeservers
- `$USER_ACCESS_TOKEN`: das Zugriffstoken des Empfängerbenutzers
- `openclaw-finalized-preview-botname`: eine Regel-ID, die pro Bot und Empfänger eindeutig ist (Muster: `openclaw-finalized-preview-<botname>`)
- `@bot:example.org`: Ihre OpenClaw-Bot-MXID, nicht die des Empfängers
</Step>
<Step title="Überprüfen">
```bash
curl -sS \
-H "Authorization: Bearer $USER_ACCESS_TOKEN" \
"https://matrix.example.org/_matrix/client/v3/pushrules/global/override/openclaw-finalized-preview-botname"
```
Testen Sie dann eine gestreamte Antwort. Im leisen Modus zeigt der Raum eine unauffällige Entwurfsvorschau an und benachrichtigt einmal, wenn der Block oder Turn abgeschlossen ist.
</Step>
</Steps>
Um die Regel später zu entfernen, senden Sie `DELETE` an dieselbe Regel-URL mit dem Token des Empfängers.
## Hinweise zu mehreren Bots
Push-Regeln werden über `ruleId` indiziert: Ein erneutes `PUT` gegen dieselbe ID aktualisiert eine einzelne Regel. Wenn mehrere OpenClaw-Bots denselben Empfänger benachrichtigen, erstellen Sie eine Regel pro Bot mit einer eindeutigen Absenderübereinstimmung.
Neue benutzerdefinierte `override`-Regeln werden vor den standardmäßigen Unterdrückungsregeln eingefügt, daher ist kein zusätzlicher Ordnungsparameter erforderlich. Die Regel wirkt sich nur auf rein textbasierte Vorschau-Bearbeitungen aus, die direkt vor Ort finalisiert werden können; Media-Fallbacks und Stale-Preview-Fallbacks verwenden die normale Matrix-Zustellung.
## Hinweise zum Homeserver
<AccordionGroup>
<Accordion title="Synapse">
Es ist keine spezielle Änderung an `homeserver.yaml` erforderlich. Wenn normale Matrix-Benachrichtigungen diesen Benutzer bereits erreichen, sind das Empfängertoken und der oben gezeigte `pushrules`-Aufruf der wichtigste Einrichtungsschritt.
Wenn Sie Synapse hinter einem Reverse-Proxy oder mit Workern betreiben, stellen Sie sicher, dass `/_matrix/client/.../pushrules/` Synapse korrekt erreicht. Die Push-Zustellung wird vom Hauptprozess oder von `synapse.app.pusher` / konfigurierten Pusher-Workern verarbeitet — stellen Sie sicher, dass diese fehlerfrei funktionieren.
</Accordion>
<Accordion title="Tuwunel">
Derselbe Ablauf wie bei Synapse; für den Marker der finalisierten Vorschau ist keine Tuwunel-spezifische Konfiguration erforderlich.
Wenn Benachrichtigungen verschwinden, während der Benutzer auf einem anderen Gerät aktiv ist, prüfen Sie, ob `suppress_push_when_active` aktiviert ist. Tuwunel hat diese Option in 1.4.2 (September 2025) hinzugefügt, und sie kann Pushes zu anderen Geräten absichtlich unterdrücken, während ein Gerät aktiv ist.
</Accordion>
</AccordionGroup>
## Verwandte Themen
- [Einrichtung des Matrix-Kanals](/de/channels/matrix)
- [Streaming-Konzepte](/de/concepts/streaming)

755
docs/de/channels/matrix.md
View File

File diff suppressed because it is too large Load Diff

121
docs/de/ci.md
View File

@ -1,107 +1,108 @@
---
read_when:
- Sie müssen verstehen, warum ein CI-Job ausgeführt wurde oder nicht.
- Sie debuggen fehlschlagende GitHub-Actions-Checks.
- Sie debuggen fehlgeschlagene GitHub-Actions-Prüfungen
summary: CI-Job-Graph, Scope-Gates und lokale Befehlsäquivalente
title: CI-Pipeline
x-i18n:
generated_at: "2026-04-23T13:59:16Z"
generated_at: "2026-04-23T14:55:33Z"
model: gpt-5.4
provider: openai
source_hash: c5a8ea0d8e428826169b0e6aced1caeb993106fe79904002125ace86b48cae1f
source_hash: e9a03440ae28a15167fc08d9c66bb1fd719ddfa1517aaecb119c80f2ad826c0d
source_path: ci.md
workflow: 15
---
# CI-Pipeline
Die CI läuft bei jedem Push nach `main` und bei jedem Pull Request. Sie verwendet intelligentes Scoping, um teure Jobs zu überspringen, wenn sich nur nicht zusammenhängende Bereiche geändert haben.
Die CI läuft bei jedem Push auf `main` und bei jedem Pull Request. Sie verwendet intelligentes Scoping, um teure Jobs zu überspringen, wenn nur nicht zusammenhängende Bereiche geändert wurden.
QA Lab hat eigene CI-Lanes außerhalb des primären intelligent gescopten Workflows. Der
Workflow `Parity gate` läuft bei passenden PR-Änderungen und per manuellem Dispatch; er
baut die private QA-Runtime und vergleicht die agentischen Packs für Mock GPT-5.4 und Opus 4.6.
Der Workflow `QA-Lab - All Lanes` läuft nachts auf `main` und per
QA Lab hat dedizierte CI-Lanes außerhalb des Haupt-Workflows mit intelligentem Scoping. Der
Workflow `Parity gate` läuft bei passenden PR-Änderungen und bei manuellem Dispatch; er
baut die private QA-Laufzeit und vergleicht die agentischen Packs für Mock GPT-5.4 und Opus 4.6.
Der Workflow `QA-Lab - All Lanes` läuft nachts auf `main` und bei
manuellem Dispatch; er fächert das Mock-Parity-Gate, die Live-Matrix-Lane und die Live-
Telegram-Lane als parallele Jobs auf. Die Live-Jobs verwenden die Umgebung `qa-live-shared`,
und die Telegram-Lane verwendet Convex-Leases. `OpenClaw Release
Checks` führt vor der Freigabe eines Releases ebenfalls dieselben QA-Lab-Lanes aus.
Checks` führt außerdem dieselben QA-Lab-Lanes vor der Release-Freigabe aus.
## Job-Überblick
## Job-Übersicht
| Job | Zweck | Wann er läuft |
| -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- |
| `preflight` | Nur-Doku-Änderungen, geänderte Scopes, geänderte extensions erkennen und das CI-Manifest bauen | Immer bei Nicht-Entwurfs-Pushes und PRs |
| `security-scm-fast` | Erkennung privater Schlüssel und Workflow-Audit über `zizmor` | Immer bei Nicht-Entwurfs-Pushes und PRs |
| `security-dependency-audit` | Produktions-Lockfile-Audit ohne Abhängigkeiten gegen npm-Advisories | Immer bei Nicht-Entwurfs-Pushes und PRs |
| `security-fast` | Erforderliches Aggregat für die schnellen Security-Jobs | Immer bei Nicht-Entwurfs-Pushes und PRs |
| `build-artifacts` | `dist/`, Control UI, Prüfungen gebauter Artefakte und wiederverwendbare nachgelagerte Artefakte bauen | Node-relevante Änderungen |
| `checks-fast-core` | Schnelle Linux-Korrektheits-Lanes wie Prüfungen für bundled/plugin-contract/protocol | Node-relevante Änderungen |
| `checks-fast-contracts-channels` | Geshardete Channel-Contract-Prüfungen mit stabilem aggregiertem Check-Ergebnis | Node-relevante Änderungen |
| `checks-node-extensions` | Vollständige Test-Shards für bundled Plugin über die gesamte Extension-Suite | Node-relevante Änderungen |
| `checks-node-core-test` | Core-Node-Test-Shards, ohne Channel-, bundled-, Contract- und Extension-Lanes | Node-relevante Änderungen |
| `extension-fast` | Fokussierte Tests nur für die geänderten bundled Plugin | Pull Requests mit Extension-Änderungen |
| `check` | Geshardetes Äquivalent zum primären lokalen Gate: Prod-Typen, Lint, Guards, Test-Typen und strikter Smoke | Node-relevante Änderungen |
| `check-additional` | Architektur-, Boundary-, Extension-Surface-Guards, Package-Boundary und Gateway-Watch-Shards | Node-relevante Änderungen |
| `build-smoke` | Smoke-Tests für gebaute CLI und Startspeicher-Smoke | Node-relevante Änderungen |
| `checks` | Verifier für Channel-Tests mit gebauten Artefakten plus nur-Push-Node-22-Kompatibilität | Node-relevante Änderungen |
| `check-docs` | Docs-Formatierung, Lint und Broken-Link-Prüfungen | Doku geändert |
| `skills-python` | Ruff + pytest für Python-basierte Skills | Python-Skill-relevante Änderungen |
| `checks-windows` | Windows-spezifische Test-Lanes | Windows-relevante Änderungen |
| `macos-node` | macOS-TypeScript-Test-Lane mit den gemeinsam genutzten gebauten Artefakten | macOS-relevante Änderungen |
| `macos-swift` | Swift-Lint, Build und Tests für die macOS-App | macOS-relevante Änderungen |
| `android` | Android-Unit-Tests für beide Flavors plus ein Debug-APK-Build | Android-relevante Änderungen |
| `preflight` | Erkennt nur-Doku-Änderungen, geänderte Scopes, geänderte Erweiterungen und baut das CI-Manifest | Immer bei Nicht-Entwurf-Pushes und PRs |
| `security-scm-fast` | Erkennung privater Schlüssel und Workflow-Audit über `zizmor` | Immer bei Nicht-Entwurf-Pushes und PRs |
| `security-dependency-audit` | Produktions-Lockfile-Audit ohne Abhängigkeiten gegen npm-Advisories | Immer bei Nicht-Entwurf-Pushes und PRs |
| `security-fast` | Erforderliche Aggregation für die schnellen Sicherheitsjobs | Immer bei Nicht-Entwurf-Pushes und PRs |
| `build-artifacts` | Baut `dist/`, das Control UI, Built-Artifact-Prüfungen und wiederverwendbare nachgelagerte Artefakte | Node-relevante Änderungen |
| `checks-fast-core` | Schnelle Linux-Korrektheits-Lanes wie Prüfungen für gebündelte Plugins/Plugin-Verträge/Protokoll | Node-relevante Änderungen |
| `checks-fast-contracts-channels` | Gesplittete Channel-Vertragsprüfungen mit einem stabilen aggregierten Prüfergebnis | Node-relevante Änderungen |
| `checks-node-extensions` | Vollständige Test-Shards für gebündelte Plugins über die gesamte Erweiterungs-Suite | Node-relevante Änderungen |
| `checks-node-core-test` | Core-Node-Test-Shards, ohne Channel-, gebündelte-, Vertrags- und Erweiterungs-Lanes | Node-relevante Änderungen |
| `extension-fast` | Fokussierte Tests nur für die geänderten gebündelten Plugins | Pull Requests mit Erweiterungsänderungen |
| `check` | Gesplittetes Äquivalent zum wichtigsten lokalen Gate: Prod-Typen, Lint, Guard-Prüfungen, Test-Typen und strenger Smoke-Test | Node-relevante Änderungen |
| `check-additional` | Architektur-, Boundary-, Erweiterungsoberflächen-Guards, Package-Boundary- und Gateway-Watch-Shards | Node-relevante Änderungen |
| `build-smoke` | Smoke-Tests für die gebaute CLI und Startup-Memory-Smoke | Node-relevante Änderungen |
| `checks` | Verifier für Channel-Tests auf Built-Artifacts plus nur bei Pushes Node-22-Kompatibilität | Node-relevante Änderungen |
| `check-docs` | Doku-Formatierung, Lint und Prüfungen auf defekte Links | Doku geändert |
| `skills-python` | Ruff + pytest für Python-gestützte Skills | Python-Skills-relevante Änderungen |
| `checks-windows` | Windows-spezifische Test-Lanes | Windows-relevante Änderungen |
| `macos-node` | macOS-TypeScript-Test-Lane unter Verwendung der gemeinsam genutzten Built-Artifacts | macOS-relevante Änderungen |
| `macos-swift` | Swift-Lint, Build und Tests für die macOS-App | macOS-relevante Änderungen |
| `android` | Android-Unit-Tests für beide Flavors plus ein Debug-APK-Build | Android-relevante Änderungen |
## Reihenfolge für schnelles Fehlschlagen
## Fail-Fast-Reihenfolge
Die Jobs sind so angeordnet, dass günstige Prüfungen fehlschlagen, bevor teure Jobs starten:
Die Jobs sind so angeordnet, dass günstige Prüfungen fehlschlagen, bevor teure Jobs laufen:
1. `preflight` entscheidet, welche Lanes überhaupt existieren. Die Logik `docs-scope` und `changed-scope` sind Schritte innerhalb dieses Jobs, keine eigenständigen Jobs.
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` und `skills-python` schlagen schnell fehl, ohne auf die schwereren Artefakt- und Plattform-Matrix-Jobs zu warten.
3. `build-artifacts` überlappt mit den schnellen Linux-Lanes, damit nachgelagerte Verbraucher starten können, sobald der gemeinsame Build bereit ist.
4. Danach fächern die schwereren Plattform- und Runtime-Lanes auf: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, das nur-PR-`extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` und `android`.
3. `build-artifacts` überlappt sich mit den schnellen Linux-Lanes, damit nachgelagerte Verbraucher starten können, sobald der gemeinsame Build bereit ist.
4. Danach fächern die schwereren Plattform- und Laufzeit-Lanes auf: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, das nur für PRs laufende `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` und `android`.
Die Scope-Logik befindet sich in `scripts/ci-changed-scope.mjs` und wird durch Unit-Tests in `src/scripts/ci-changed-scope.test.ts` abgedeckt.
Änderungen an CI-Workflows validieren den Node-CI-Graphen sowie das Workflow-Linting, erzwingen aber für sich allein keine nativen Windows-, Android- oder macOS-Builds; diese Plattform-Lanes bleiben auf Änderungen an der jeweiligen Plattformquelle beschränkt.
Windows-Node-Prüfungen sind auf Windows-spezifische Prozess-/Pfad-Wrapper, npm/pnpm/UI-Runner-Helfer, Package-Manager-Konfiguration und die CI-Workflow-Oberflächen begrenzt, die diese Lane ausführen; nicht zusammenhängende Source-, Plugin-, Install-Smoke- und nur-Test-Änderungen bleiben auf den Linux-Node-Lanes, damit sie keinen Windows-Worker mit 16 vCPU für Abdeckung reservieren, die bereits durch die normalen Test-Shards ausgeübt wird.
Der separate Workflow `install-smoke` verwendet dasselbe Scope-Skript über seinen eigenen `preflight`-Job wieder. Er berechnet `run_install_smoke` aus dem engeren Signal `changed-smoke`, sodass Docker-/Install-Smoke bei Installations-, Packaging-, containerrelevanten Änderungen, Production-Änderungen an gebündelten extensions sowie den Core-Surfaces für Plugin/Channel/Gateway/Plugin SDK läuft, die die Docker-Smoke-Jobs abdecken. Nur-Test- und nur-Doku-Änderungen reservieren keine Docker-Worker. Sein QR-Package-Smoke erzwingt, dass die Docker-Schicht `pnpm install` erneut ausgeführt wird, wobei der BuildKit-pnpm-Store-Cache erhalten bleibt, sodass die Installation weiterhin getestet wird, ohne bei jedem Lauf Abhängigkeiten neu herunterzuladen. Sein Gateway-Network-e2e verwendet das früher im Job gebaute Runtime-Image wieder, sodass echte container-zu-container-WebSocket-Abdeckung hinzukommt, ohne einen weiteren Docker-Build hinzuzufügen. Lokal baut `test:docker:all` ein gemeinsames Live-Test-Image und ein gemeinsames Built-App-Image aus `scripts/e2e/Dockerfile` vor und führt dann die Live-/E2E-Smoke-Lanes parallel mit `OPENCLAW_SKIP_DOCKER_BUILD=1` aus; passen Sie die Standard-Parallelität von 4 mit `OPENCLAW_DOCKER_ALL_PARALLELISM` an. Das lokale Aggregat plant standardmäßig nach dem ersten Fehler keine neuen gepoolten Lanes mehr ein, und jede Lane hat ein 120-Minuten-Timeout, das mit `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` überschrieben werden kann. Start- oder Provider-sensitive Lanes laufen exklusiv nach dem parallelen Pool. Der wiederverwendbare Live-/E2E-Workflow spiegelt das Muster mit gemeinsamem Image, indem er vor der Docker-Matrix ein SHA-getaggtes GHCR-Docker-E2E-Image baut und pusht und dann die Matrix mit `OPENCLAW_SKIP_DOCKER_BUILD=1` ausführt. Der geplante Live-/E2E-Workflow führt täglich die vollständige Docker-Suite des Release-Pfads aus. QR- und Installer-Docker-Tests behalten ihre eigenen installationsfokussierten Dockerfiles. Ein separater Job `docker-e2e-fast` führt das begrenzte Docker-Profil für bundled Plugin unter einem Befehls-Timeout von 120 Sekunden aus: Dependency-Reparatur für setup-entry plus synthetische Isolierung von Fehlern im bundled-loader. Die vollständige Matrix für bundled Update/Channel bleibt manuell/Vollsuite, weil sie wiederholte echte npm-update- und doctor-repair-Durchläufe ausführt.
Die Scope-Logik lebt in `scripts/ci-changed-scope.mjs` und ist durch Unit-Tests in `src/scripts/ci-changed-scope.test.ts` abgedeckt.
Änderungen am CI-Workflow validieren den Node-CI-Graphen plus Workflow-Linting, erzwingen aber nicht selbst Windows-, Android- oder macOS-native Builds; diese Plattform-Lanes bleiben auf Änderungen im Plattform-Quellcode beschränkt.
Windows-Node-Prüfungen sind auf Windows-spezifische Prozess-/Pfad-Wrapper, npm/pnpm/UI-Runner-Hilfen, Package-Manager-Konfiguration und die CI-Workflow-Oberflächen beschränkt, die diese Lane ausführen; nicht zusammenhängende Quellcode-, Plugin-, Install-Smoke- und reine Teständerungen bleiben auf den Linux-Node-Lanes, damit sie keinen Windows-Worker mit 16 vCPU für Abdeckung reservieren, die bereits durch die normalen Test-Shards ausgeübt wird.
Der separate Workflow `install-smoke` verwendet dasselbe Scope-Skript über seinen eigenen Job `preflight` erneut. Er berechnet `run_install_smoke` aus dem enger gefassten Signal changed-smoke, sodass Docker/Install-Smoke bei install-, packaging-, container-relevanten Änderungen, Änderungen an der Produktionslogik gebündelter Erweiterungen und an den Core-Oberflächen Plugin/Channel/Gateway/Plugin SDK läuft, die die Docker-Smoke-Jobs ausüben. Reine Test- und reine Doku-Änderungen reservieren keine Docker-Worker. Sein QR-Package-Smoke erzwingt, dass die Docker-Schicht `pnpm install` erneut läuft, wobei der BuildKit-pnpm-Store-Cache erhalten bleibt, sodass die Installation weiter geprüft wird, ohne bei jedem Lauf Abhängigkeiten erneut herunterzuladen. Sein gateway-network-e2e verwendet das früher im Job gebaute Runtime-Image erneut, sodass echte WebSocket-Abdeckung zwischen Containern hinzugefügt wird, ohne einen weiteren Docker-Build hinzuzufügen. Lokal baut `test:docker:all` ein gemeinsames Live-Test-Image und ein gemeinsames Built-App-Image aus `scripts/e2e/Dockerfile` vor und führt dann die Live-/E2E-Smoke-Lanes parallel mit `OPENCLAW_SKIP_DOCKER_BUILD=1` aus; passen Sie die Standard-Parallelität von 4 mit `OPENCLAW_DOCKER_ALL_PARALLELISM` an. Das lokale Aggregat plant standardmäßig nach dem ersten Fehler keine neuen gepoolten Lanes mehr ein, und jede Lane hat ein Timeout von 120 Minuten, überschreibbar mit `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Startup- oder Provider-sensitive Lanes laufen exklusiv nach dem parallelen Pool. Der wiederverwendbare Live-/E2E-Workflow bildet das Muster mit gemeinsamem Image nach, indem er vor der Docker-Matrix ein SHA-getaggtes GHCR-Docker-E2E-Image baut und pusht und dann die Matrix mit `OPENCLAW_SKIP_DOCKER_BUILD=1` ausführt. Der geplante Live-/E2E-Workflow führt täglich die vollständige Docker-Suite des Release-Pfads aus. QR- und Installer-Docker-Tests behalten ihre eigenen install-fokussierten Dockerfiles. Ein separater Job `docker-e2e-fast` führt das begrenzte gebündelte Plugin-Docker-Profil mit einem Befehls-Timeout von 120 Sekunden aus: setup-entry-Abhängigkeitsreparatur plus synthetische Isolierung von Fehlern im gebündelten Loader. Die vollständige Matrix für gebündelte Updates/Channel bleibt manuell/vollständige Suite, weil sie wiederholt echte npm-Update- und doctor-Reparaturdurchläufe ausführt.
Die Logik für lokale Changed-Lanes befindet sich in `scripts/changed-lanes.mjs` und wird von `scripts/check-changed.mjs` ausgeführt. Dieses lokale Gate ist bei Architekturgrenzen strenger als das breite CI-Plattform-Scoping: Änderungen an der Core-Production führen Prod-Typecheck für den Core plus Core-Tests aus, reine Core-Test-Änderungen führen nur Test-Typecheck/Tests für den Core aus, Änderungen an der Extension-Production führen Prod-Typecheck für extensions plus Extension-Tests aus, und reine Extension-Test-Änderungen führen nur Test-Typecheck/Tests für extensions aus. Änderungen am öffentlichen Plugin SDK oder an plugin-contract erweitern die Validierung auf extensions, weil extensions von diesen Core-Contracts abhängen. Reine Versions-Bumps an Release-Metadaten führen gezielte Prüfungen für Version/Konfiguration/Root-Abhängigkeiten aus. Unbekannte Änderungen an Root/Konfiguration schlagen sicherheitshalber auf alle Lanes durch.
Die lokale Logik für Changed-Lanes lebt in `scripts/changed-lanes.mjs` und wird durch `scripts/check-changed.mjs` ausgeführt. Dieses lokale Gate ist bei Architekturgrenzen strenger als das breite CI-Plattform-Scoping: Änderungen an der Core-Produktionslogik führen Core-Prod-Typecheck plus Core-Tests aus, reine Core-Teständerungen führen nur Core-Test-Typecheck/-Tests aus, Änderungen an der Produktionslogik von Erweiterungen führen Erweiterungs-Prod-Typecheck plus Erweiterungstests aus, und reine Erweiterungsteständerungen führen nur Erweiterungstest-Typecheck/-Tests aus. Änderungen an öffentlichem Plugin SDK oder Plugin-Verträgen erweitern die Validierung auf Erweiterungen, weil Erweiterungen von diesen Core-Verträgen abhängen. Reine Versionserhöhungen in Release-Metadaten führen gezielte Prüfungen für Version/Konfiguration/Root-Abhängigkeiten aus. Unbekannte Root-/Konfigurationsänderungen fallen aus Sicherheitsgründen auf alle Lanes zurück.
Bei Pushes fügt die Matrix `checks` die nur-Push-Lane `compat-node22` hinzu. Bei Pull Requests wird diese Lane übersprungen, und die Matrix bleibt auf die normalen Test-/Channel-Lanes fokussiert.
Bei Pushes fügt die Matrix `checks` die nur bei Pushes laufende Lane `compat-node22` hinzu. Bei Pull Requests wird diese Lane übersprungen, und die Matrix bleibt auf die normalen Test-/Channel-Lanes fokussiert.
Die langsamsten Node-Testfamilien sind aufgeteilt oder ausbalanciert, damit jeder Job klein bleibt: Channel-Contracts teilen Registry- und Core-Abdeckung in insgesamt sechs gewichtete Shards auf, Tests für bundled Plugin werden über sechs Extension-Worker ausbalanciert, Auto-Reply läuft als drei ausbalancierte Worker statt sechs winziger Worker, und agentische Gateway-/Plugin-Konfigurationen werden über die bestehenden agentischen Node-Jobs nur für Source verteilt, statt auf gebaute Artefakte zu warten. Breite Browser-, QA-, Medien- und sonstige Plugin-Tests verwenden ihre eigenen dedizierten Vitest-Konfigurationen statt des gemeinsamen Catch-all für Plugin. Die breite Agents-Lane verwendet den gemeinsamen dateiparallelen Vitest-Scheduler, weil sie von Imports/Terminierung dominiert ist statt von einer einzelnen langsamen Testdatei. `runtime-config` läuft mit dem Shard `infra core-runtime`, damit der gemeinsame Runtime-Shard nicht das Tail besitzt. `check-additional` hält Compile-/Canary-Arbeit für Package-Boundary zusammen und trennt Runtime-Topologie-Architektur von Gateway-Watch-Abdeckung; der Boundary-Guard-Shard führt seine kleinen unabhängigen Guards gleichzeitig innerhalb eines Jobs aus. Gateway-Watch, Channel-Tests und der Shard `core support-boundary` laufen gleichzeitig innerhalb von `build-artifacts`, nachdem `dist/` und `dist-runtime/` bereits gebaut wurden. So bleiben ihre alten Check-Namen als leichtgewichtige Verifier-Jobs erhalten, während zwei zusätzliche Blacksmith-Worker und eine zweite Artifact-Consumer-Queue vermieden werden.
Android-CI führt sowohl `testPlayDebugUnitTest` als auch `testThirdPartyDebugUnitTest` aus und baut dann das Play-Debug-APK. Der Third-Party-Flavor hat kein separates Source-Set oder Manifest; seine Unit-Test-Lane kompiliert diesen Flavor dennoch mit den SMS-/Call-Log-BuildConfig-Flags, vermeidet dabei aber einen doppelten Packaging-Job für Debug-APKs bei jedem Android-relevanten Push.
`extension-fast` ist nur für PRs, weil Push-Läufe bereits die vollständigen Test-Shards für bundled Plugin ausführen. Das erhält schnelles Feedback zu geänderten Plugin für Reviews, ohne auf `main` einen zusätzlichen Blacksmith-Worker für Abdeckung zu reservieren, die bereits in `checks-node-extensions` vorhanden ist.
Die langsamsten Node-Testfamilien werden aufgeteilt oder ausbalanciert, damit jeder Job klein bleibt, ohne Runner übermäßig zu reservieren: Channel-Verträge laufen als drei gewichtete Shards, Tests für gebündelte Plugins werden über sechs Erweiterungs-Worker verteilt, kleine Core-Unit-Lanes werden gepaart, Auto-Reply läuft als drei ausbalancierte Worker statt sechs winziger Worker, und agentische Gateway-/Plugin-Konfigurationen werden über die vorhandenen agentischen Node-Quellcode-Jobs verteilt, statt auf Built-Artifacts zu warten. Breite Browser-, QA-, Medien- und sonstige Plugin-Tests verwenden ihre dedizierten Vitest-Konfigurationen statt des gemeinsamen Plugin-Sammel-Setups. Die breite Agents-Lane verwendet den gemeinsamen Dateiparallel-Scheduler von Vitest, weil sie von Importen/Planung dominiert wird statt von einer einzelnen langsamen Testdatei. `runtime-config` läuft mit dem Shard infra core-runtime, damit nicht der gemeinsame Runtime-Shard den Nachlauf besitzt. `check-additional` hält Package-Boundary-Compile-/Canary-Arbeit zusammen und trennt Laufzeittopologie-Architektur von Gateway-Watch-Abdeckung; der Boundary-Guard-Shard führt seine kleinen unabhängigen Guards innerhalb eines Jobs parallel aus. Gateway-Watch, Channel-Tests und der Core-Support-Boundary-Shard laufen innerhalb von `build-artifacts` gleichzeitig, nachdem `dist/` und `dist-runtime/` bereits gebaut wurden; so bleiben ihre alten Prüfnamen als leichtgewichtige Verifier-Jobs erhalten, während zwei zusätzliche Blacksmith-Worker und eine zweite Warteschlange für Artefakt-Verbraucher vermieden werden.
Android-CI führt sowohl `testPlayDebugUnitTest` als auch `testThirdPartyDebugUnitTest` aus und baut dann das Play-Debug-APK. Der Third-Party-Flavor hat kein separates Source-Set und kein eigenes Manifest; seine Unit-Test-Lane kompiliert diesen Flavor dennoch mit den SMS-/Call-Log-BuildConfig-Flags und vermeidet gleichzeitig einen doppelten Packaging-Job für Debug-APK bei jedem Android-relevanten Push.
`extension-fast` ist nur für PRs, weil Push-Läufe bereits die vollständigen Shards für gebündelte Plugins ausführen. Das sorgt für Feedback zu geänderten Plugins in Reviews, ohne auf `main` einen zusätzlichen Blacksmith-Worker für Abdeckung zu reservieren, die bereits in `checks-node-extensions` vorhanden ist.
GitHub kann ersetzte Jobs als `cancelled` markieren, wenn ein neuerer Push auf derselben PR oder derselben `main`-Ref landet. Behandeln Sie das als CI-Rauschen, es sei denn, der neueste Lauf für dieselbe Ref schlägt ebenfalls fehl. Aggregierte Shard-Checks verwenden `!cancelled() && always()`, damit sie normale Shard-Fehler weiterhin melden, aber nicht in die Queue kommen, nachdem der gesamte Workflow bereits ersetzt wurde.
Der CI-Concurrency-Key ist versioniert (`CI-v7-*`), damit ein zombiehafter GitHub-Eintrag in einer alten Queue-Gruppe neuere Main-Läufe nicht auf unbestimmte Zeit blockieren kann.
GitHub kann ersetzte Jobs als `cancelled` markieren, wenn ein neuerer Push auf derselben PR oder demselben `main`-Ref landet. Behandeln Sie das als CI-Rauschen, außer wenn der neueste Lauf für denselben Ref ebenfalls fehlschlägt. Aggregierte Shard-Prüfungen verwenden `!cancelled() && always()`, sodass sie weiterhin normale Shard-Fehler melden, aber nicht in die Queue gestellt werden, nachdem der gesamte Workflow bereits ersetzt wurde.
Der CI-Concurrency-Key ist versioniert (`CI-v7-*`), sodass ein GitHub-seitiger Zombie in einer alten Queue-Gruppe neuere Main-Läufe nicht auf unbestimmte Zeit blockieren kann.
## Runner
| Runner | Jobs |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ubuntu-24.04` | `preflight`, schnelle Security-Jobs und Aggregate (`security-scm-fast`, `security-dependency-audit`, `security-fast`), schnelle Prüfungen für protocol/contract/bundled, geshardete Channel-Contract-Prüfungen, `check`-Shards außer Lint, `check-additional`-Shards und -Aggregate, Verifier-Aggregate für Node-Tests, Docs-Prüfungen, Python-Skills, workflow-sanity, labeler, auto-response; der Preflight von install-smoke verwendet ebenfalls GitHub-gehostetes Ubuntu, damit die Blacksmith-Matrix früher in die Queue gehen kann |
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, Linux-Node-Test-Shards, Test-Shards für bundled Plugin, `android` |
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, das weiterhin so CPU-sensitiv ist, dass 8 vCPU teurer waren, als sie eingespart haben; install-smoke-Docker-Builds, bei denen die Queue-Zeit für 32 vCPU teurer war, als sie eingespart hat |
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
| `blacksmith-6vcpu-macos-latest` | `macos-node` auf `openclaw/openclaw`; Forks fallen auf `macos-latest` zurück |
| `blacksmith-12vcpu-macos-latest` | `macos-swift` auf `openclaw/openclaw`; Forks fallen auf `macos-latest` zurück |
| Runner | Jobs |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ubuntu-24.04` | `preflight`, schnelle Sicherheitsjobs und Aggregate (`security-scm-fast`, `security-dependency-audit`, `security-fast`), schnelle Prüfungen für Protokoll/Verträge/gebündelte Plugins, gesplittete Channel-Vertragsprüfungen, `check`-Shards außer Lint, `check-additional`-Shards und -Aggregate, Aggregate-Verifier für Node-Tests, Doku-Prüfungen, Python-Skills, workflow-sanity, labeler, auto-response; preflight für install-smoke verwendet ebenfalls GitHub-gehostetes Ubuntu, sodass die Blacksmith-Matrix früher in die Queue gestellt werden kann |
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, Linux-Node-Test-Shards, Test-Shards für gebündelte Plugins, `android` |
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, das CPU-sensitiv genug bleibt, dass 8 vCPU mehr Kosten verursachten, als sie einsparten; install-smoke-Docker-Builds, bei denen die Queue-Zeit für 32 vCPU mehr kostete, als sie einsparten |
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
| `blacksmith-6vcpu-macos-latest` | `macos-node` auf `openclaw/openclaw`; Forks fallen auf `macos-latest` zurück |
| `blacksmith-12vcpu-macos-latest` | `macos-swift` auf `openclaw/openclaw`; Forks fallen auf `macos-latest` zurück |
## Lokale Äquivalente
```bash
pnpm changed:lanes # den lokalen Changed-Lane-Klassifizierer für origin/main...HEAD prüfen
pnpm check:changed # intelligentes lokales Gate: geänderter Typecheck/Lint/Tests nach Boundary-Lane
pnpm check # schnelles lokales Gate: Produktions-tsgo + geshardetes Lint + parallele schnelle Guards
pnpm changed:lanes # lokalen Changed-Lane-Klassifizierer für origin/main...HEAD prüfen
pnpm check:changed # intelligentes lokales Gate: geänderte Typechecks/Lint/Tests nach Boundary-Lane
pnpm check # schnelles lokales Gate: Produktions-tsgo + gesplittetes Lint + parallele schnelle Guards
pnpm check:test-types
pnpm check:timed # dasselbe Gate mit Timing pro Phase
pnpm check:timed # dasselbe Gate mit Timings pro Phase
pnpm build:strict-smoke
pnpm check:architecture
pnpm test:gateway:watch-regression
pnpm test # Vitest-Tests
pnpm test:channels
pnpm test:contracts:channels
pnpm check:docs # Docs-Formatierung + Lint + Broken-Links
pnpm build # dist bauen, wenn CI-Artefakt-/build-smoke-Lanes relevant sind
node scripts/ci-run-timings.mjs <run-id> # Wall Time, Queue-Zeit und langsamste Jobs zusammenfassen
pnpm check:docs # Doku-Formatierung + Lint + defekte Links
pnpm build # `dist` bauen, wenn CI-Artefakt-/build-smoke-Lanes relevant sind
node scripts/ci-run-timings.mjs <run-id> # Laufzeit, Queue-Zeit und langsamste Jobs zusammenfassen
node scripts/ci-run-timings.mjs --recent 10 # aktuelle erfolgreiche main-CI-Läufe vergleichen
```

129
docs/de/gateway/authentication.md
View File

@ -1,37 +1,41 @@
---
read_when:
- Debugging von Modellauthentifizierung oder ablaufendem OAuth
- Dokumentation von Authentifizierung oder Speicherung von Anmeldedaten
- Debugging der Modellauthentifizierung oder des OAuth-Ablaufs
- Dokumentation der Authentifizierung oder der Speicherung von Anmeldedaten
summary: 'Modellauthentifizierung: OAuth, API-Schlüssel, Wiederverwendung der Claude CLI und Anthropic-Setup-Token'
title: Authentifizierung
x-i18n:
generated_at: "2026-04-07T06:14:27Z"
generated_at: "2026-04-23T14:55:29Z"
model: gpt-5.4
provider: openai
source_hash: 9db0ad9eccd7e3e3ca328adaad260bc4288a8ccdbe2dc0c24d9fd049b7ab9231
source_hash: 37a7c20872b915d1d079f0578c933e43cbdb97eca1c60d8c4e6e5137ca83f8b2
source_path: gateway/authentication.md
workflow: 15
---
# Authentifizierung (Modell-Provider)
# Authentifizierung (Modellanbieter)
<Note>
Diese Seite behandelt die **Authentifizierung von Modell-Providern** (API-Schlüssel, OAuth, Wiederverwendung der Claude CLI und Anthropic-Setup-Token). Informationen zur **Authentifizierung von Gateway-Verbindungen** (Token, Passwort, Trusted Proxy) finden Sie unter [Configuration](/de/gateway/configuration) und [Trusted Proxy Auth](/de/gateway/trusted-proxy-auth).
Diese Seite behandelt die Authentifizierung von **Modellanbietern** (API-Schlüssel, OAuth, Wiederverwendung der Claude CLI und Anthropic-Setup-Token). Informationen zur Authentifizierung der **Gateway-Verbindung** (Token, Passwort, trusted-proxy) finden Sie unter [Configuration](/de/gateway/configuration) und [Trusted Proxy Auth](/de/gateway/trusted-proxy-auth).
</Note>
OpenClaw unterstützt OAuth und API-Schlüssel für Modell-Provider. Für dauerhaft laufende Gateway-Hosts sind API-Schlüssel normalerweise die am besten vorhersehbare Option. Abonnement-/OAuth-Abläufe werden ebenfalls unterstützt, wenn sie zu Ihrem Provider-Kontomodell passen.
OpenClaw unterstützt OAuth und API-Schlüssel für Modellanbieter. Für dauerhaft
laufende Gateway-Hosts sind API-Schlüssel in der Regel die vorhersehbarste
Option. Abonnement-/OAuth-Abläufe werden ebenfalls unterstützt, wenn sie zu
Ihrem Anbieterkonto-Modell passen.
Unter [/concepts/oauth](/de/concepts/oauth) finden Sie den vollständigen OAuth-Ablauf und das Speicherlayout.
Für SecretRef-basierte Authentifizierung (`env`/`file`/`exec`-Provider) siehe [Secrets Management](/de/gateway/secrets).
Zu Regeln für die Eignung von Anmeldedaten und Reason-Codes, die von `models status --probe` verwendet werden, siehe
[Auth Credential Semantics](/de/auth-credential-semantics).
Für SecretRef-basierte Authentifizierung (Anbieter `env`/`file`/`exec`) siehe [Secrets Management](/de/gateway/secrets).
Für Regeln zur Berechtigung von Anmeldedaten bzw. Reason-Codes, die von `models status --probe` verwendet werden, siehe
[Semantik von Auth-Anmeldedaten](/de/auth-credential-semantics).
## Empfohlene Einrichtung (API-Schlüssel, beliebiger Provider)
## Empfohlene Einrichtung (API-Schlüssel, beliebiger Anbieter)
Wenn Sie ein langlebiges Gateway betreiben, beginnen Sie mit einem API-Schlüssel für Ihren gewählten Provider.
Speziell für Anthropic ist die Authentifizierung per API-Schlüssel weiterhin die am besten vorhersehbare Server-Einrichtung, aber OpenClaw unterstützt auch die Wiederverwendung einer lokalen Claude CLI-Anmeldung.
Wenn Sie ein langlebiges Gateway betreiben, beginnen Sie mit einem API-Schlüssel für Ihren gewählten
Anbieter.
Speziell für Anthropic ist die Authentifizierung per API-Schlüssel weiterhin die vorhersehbarste Servereinrichtung, aber OpenClaw unterstützt auch die Wiederverwendung einer lokalen Claude CLI-Anmeldung.
1. Erstellen Sie in der Konsole Ihres Providers einen API-Schlüssel.
1. Erstellen Sie in der Konsole Ihres Anbieters einen API-Schlüssel.
2. Legen Sie ihn auf dem **Gateway-Host** ab (dem Rechner, auf dem `openclaw gateway` läuft).
```bash
@ -39,7 +43,8 @@ export <PROVIDER>_API_KEY="..."
openclaw models status
```
3. Wenn das Gateway unter systemd/launchd läuft, legen Sie den Schlüssel vorzugsweise in `~/.openclaw/.env` ab, damit der Daemon ihn lesen kann:
3. Wenn das Gateway unter systemd/launchd läuft, legen Sie den Schlüssel
vorzugsweise in `~/.openclaw/.env` ab, damit der Daemon ihn lesen kann:
```bash
cat >> ~/.openclaw/.env <<'EOF'
@ -57,16 +62,40 @@ openclaw doctor
Wenn Sie Umgebungsvariablen nicht selbst verwalten möchten, kann das Onboarding
API-Schlüssel für die Nutzung durch den Daemon speichern: `openclaw onboard`.
Siehe [Help](/de/help) für Details zur Vererbung von Umgebungsvariablen (`env.shellEnv`,
`~/.openclaw/.env`, systemd/launchd).
Einzelheiten zur Vererbung von Umgebungsvariablen (`env.shellEnv`,
`~/.openclaw/.env`, systemd/launchd) finden Sie unter [Help](/de/help).
## Anthropic: Claude CLI und Token-Kompatibilität
Die Authentifizierung per Anthropic-Setup-Token ist in OpenClaw weiterhin als unterstützter Token-Pfad verfügbar. Mitarbeitende von Anthropic haben uns inzwischen mitgeteilt, dass die Nutzung der Claude CLI im Stil von OpenClaw wieder erlaubt ist. Deshalb behandelt OpenClaw die Wiederverwendung der Claude CLI und die Nutzung von `claude -p` für diese Integration als zulässig, sofern Anthropic keine neue Richtlinie veröffentlicht. Wenn die Wiederverwendung der Claude CLI auf dem Host verfügbar ist, ist dies jetzt der bevorzugte Pfad.
Die Authentifizierung per Anthropic-Setup-Token ist in OpenClaw weiterhin als unterstützter
Token-Pfad verfügbar. Anthropic-Mitarbeitende haben uns inzwischen mitgeteilt, dass die Nutzung der Claude CLI im OpenClaw-Stil
wieder erlaubt ist. Daher behandelt OpenClaw die Wiederverwendung der Claude CLI und die Verwendung von `claude -p`
für diese Integration als zulässig, sofern Anthropic keine neue Richtlinie veröffentlicht. Wenn die
Wiederverwendung der Claude CLI auf dem Host verfügbar ist, ist dies jetzt der bevorzugte Pfad.
Für langlebige Gateway-Hosts bleibt ein Anthropic-API-Schlüssel dennoch die am besten vorhersehbare Einrichtung. Wenn Sie eine vorhandene Claude-Anmeldung auf demselben Host wiederverwenden möchten, nutzen Sie beim Onboarding/Konfigurieren den Anthropic-Claude-CLI-Pfad.
Für langlebige Gateway-Hosts ist ein Anthropic-API-Schlüssel weiterhin die am besten vorhersagbare
Einrichtung. Wenn Sie eine bestehende Claude-Anmeldung auf demselben Host wiederverwenden möchten, nutzen Sie den
Anthropic-Claude-CLI-Pfad in Onboarding/Konfiguration.
Manuelle Tokeneingabe (beliebiger Provider; schreibt `auth-profiles.json` + aktualisiert die Konfiguration):
Empfohlene Host-Einrichtung für die Wiederverwendung der Claude CLI:
```bash
# Auf dem Gateway-Host ausführen
claude auth login
claude auth status --text
openclaw models auth login --provider anthropic --method cli --set-default
```
Dies ist eine Einrichtung in zwei Schritten:
1. Melden Sie Claude Code selbst auf dem Gateway-Host bei Anthropic an.
2. Weisen Sie OpenClaw an, die Anthropic-Modellauswahl auf das lokale Backend `claude-cli`
umzustellen und das passende OpenClaw-Authentifizierungsprofil zu speichern.
Wenn `claude` nicht im `PATH` liegt, installieren Sie entweder zuerst Claude Code oder setzen Sie
`agents.defaults.cliBackends.claude-cli.command` auf den tatsächlichen Pfad zur Binärdatei.
Manuelle Token-Eingabe (beliebiger Anbieter; schreibt `auth-profiles.json` und aktualisiert die Konfiguration):
```bash
openclaw models auth paste-token --provider openrouter
@ -76,9 +105,9 @@ Verweise auf Auth-Profile werden auch für statische Anmeldedaten unterstützt:
- Anmeldedaten vom Typ `api_key` können `keyRef: { source, provider, id }` verwenden
- Anmeldedaten vom Typ `token` können `tokenRef: { source, provider, id }` verwenden
- Profile im OAuth-Modus unterstützen keine SecretRef-Anmeldedaten; wenn `auth.profiles.<id>.mode` auf `"oauth"` gesetzt ist, wird SecretRef-gestützte `keyRef`-/`tokenRef`-Eingabe für dieses Profil abgelehnt.
- Profile im OAuth-Modus unterstützen keine SecretRef-Anmeldedaten; wenn `auth.profiles.<id>.mode` auf `"oauth"` gesetzt ist, wird eine durch SecretRef gestützte Eingabe über `keyRef`/`tokenRef` für dieses Profil abgelehnt.
Automatisierungsfreundliche Prüfung (Exit `1` bei abgelaufen/fehlend, `2` bei bald ablaufend):
Automatisierungsfreundliche Prüfung (Exit-Code `1`, wenn abgelaufen/fehlend, `2`, wenn bald ablaufend):
```bash
openclaw models status --check
@ -92,21 +121,26 @@ openclaw models status --probe
Hinweise:
- Probe-Zeilen können aus Auth-Profilen, Umgebungs-Anmeldedaten oder `models.json` stammen.
- Wenn ein explizites `auth.order.<provider>` ein gespeichertes Profil auslässt, meldet die Probe für dieses Profil `excluded_by_auth_order`, statt es zu verwenden.
- Wenn Authentifizierung vorhanden ist, OpenClaw aber kein sondierbares Modellkandidat für diesen Provider auflösen kann, meldet die Probe `status: no_model`.
- Abkühlzeiten bei Rate Limits können modellspezifisch sein. Ein Profil, das für ein Modell abkühlt, kann für ein verwandtes Modell desselben Providers weiterhin nutzbar sein.
- Probe-Zeilen können aus Auth-Profilen, Anmeldedaten aus der Umgebung oder `models.json` stammen.
- Wenn ein explizites `auth.order.<provider>` ein gespeichertes Profil auslässt, meldet die Probe
für dieses Profil `excluded_by_auth_order`, anstatt es zu versuchen.
- Wenn Authentifizierung vorhanden ist, OpenClaw aber kein sondierbares Modell als Kandidat für
diesen Anbieter auflösen kann, meldet die Probe `status: no_model`.
- Cooldowns für Rate-Limits können modellspezifisch sein. Ein Profil, das für ein
Modell im Cooldown ist, kann für ein verwandtes Modell desselben Anbieters weiterhin nutzbar sein.
Optionale Betriebsskripte (systemd/Termux) sind hier dokumentiert:
[Auth monitoring scripts](/de/help/scripts#auth-monitoring-scripts)
[Skripte zur Auth-Überwachung](/de/help/scripts#auth-monitoring-scripts)
## Anthropic-Hinweis
## Hinweis zu Anthropic
Das Anthropic-Backend `claude-cli` wird wieder unterstützt.
Das Backend `claude-cli` von Anthropic wird wieder unterstützt.
- Mitarbeitende von Anthropic haben uns mitgeteilt, dass dieser OpenClaw-Integrationspfad wieder erlaubt ist.
- OpenClaw behandelt daher die Wiederverwendung der Claude CLI und die Nutzung von `claude -p` für Anthropic-gestützte Läufe als zulässig, sofern Anthropic keine neue Richtlinie veröffentlicht.
- Anthropic-API-Schlüssel bleiben die am besten vorhersehbare Wahl für langlebige Gateway-Hosts und eine explizite serverseitige Kontrolle der Abrechnung.
- Anthropic-Mitarbeitende haben uns mitgeteilt, dass dieser OpenClaw-Integrationspfad wieder erlaubt ist.
- OpenClaw behandelt daher die Wiederverwendung der Claude CLI und die Verwendung von `claude -p`
für von Anthropic unterstützte Ausführungen als zulässig, sofern Anthropic keine neue Richtlinie veröffentlicht.
- Anthropic-API-Schlüssel bleiben die am besten vorhersagbare Wahl für langlebige Gateway-Hosts
und eine explizite serverseitige Kontrolle der Abrechnung.
## Status der Modellauthentifizierung prüfen
@ -117,32 +151,34 @@ openclaw doctor
## Verhalten bei der Rotation von API-Schlüsseln (Gateway)
Einige Provider unterstützen, eine Anfrage mit alternativen Schlüsseln erneut zu versuchen, wenn ein API-Aufruf an ein Rate Limit des Providers stößt.
Einige Anbieter unterstützen das erneute Versuchen einer Anfrage mit alternativen Schlüsseln, wenn ein API-Aufruf
an ein Rate-Limit des Anbieters stößt.
- Prioritätsreihenfolge:
- `OPENCLAW_LIVE_<PROVIDER>_KEY` (einzelne Überschreibung)
- `<PROVIDER>_API_KEYS`
- `<PROVIDER>_API_KEY`
- `<PROVIDER>_API_KEY_*`
- Google-Provider schließen zusätzlich `GOOGLE_API_KEY` als weiteren Fallback ein.
- Google-Anbieter enthalten außerdem `GOOGLE_API_KEY` als zusätzlichen Fallback.
- Dieselbe Schlüsselliste wird vor der Verwendung dedupliziert.
- OpenClaw versucht es mit dem nächsten Schlüssel nur bei Rate-Limit-Fehlern erneut (zum Beispiel `429`, `rate_limit`, `quota`, `resource exhausted`, `Too many concurrent
- OpenClaw versucht den nächsten Schlüssel nur bei Rate-Limit-Fehlern erneut (zum Beispiel
`429`, `rate_limit`, `quota`, `resource exhausted`, `Too many concurrent
requests`, `ThrottlingException`, `concurrency limit reached` oder
`workers_ai ... quota limit exceeded`).
- Andere Fehler als Rate-Limit-Fehler werden nicht mit alternativen Schlüsseln erneut versucht.
- Fehler, die keine Rate-Limit-Fehler sind, werden nicht mit alternativen Schlüsseln erneut versucht.
- Wenn alle Schlüssel fehlschlagen, wird der endgültige Fehler des letzten Versuchs zurückgegeben.
## Steuern, welche Anmeldedaten verwendet werden
### Pro Sitzung (Chat-Befehl)
Verwenden Sie `/model <alias-or-id>@<profileId>`, um bestimmte Provider-Anmeldedaten für die aktuelle Sitzung festzulegen (Beispiel-Profile-IDs: `anthropic:default`, `anthropic:work`).
Verwenden Sie `/model <alias-or-id>@<profileId>`, um bestimmte Anmeldedaten eines Anbieters für die aktuelle Sitzung festzulegen (Beispiel für Profil-IDs: `anthropic:default`, `anthropic:work`).
Verwenden Sie `/model` (oder `/model list`) für eine kompakte Auswahl; verwenden Sie `/model status` für die vollständige Ansicht (Kandidaten + nächstes Auth-Profil sowie Details zu Provider-Endpunkten, falls konfiguriert).
Verwenden Sie `/model` (oder `/model list`) für eine kompakte Auswahl; verwenden Sie `/model status` für die vollständige Ansicht (Kandidaten + nächstes Auth-Profil sowie Details zum Anbieter-Endpunkt, wenn konfiguriert).
### Pro Agent (CLI-Überschreibung)
Legen Sie eine explizite Überschreibung der Reihenfolge von Auth-Profilen für einen Agenten fest (gespeichert in dessen `auth-state.json`):
Legen Sie eine explizite Überschreibung der Reihenfolge von Auth-Profilen für einen Agenten fest (gespeichert in der `auth-state.json` dieses Agenten):
```bash
openclaw models auth order get --provider anthropic
@ -151,14 +187,17 @@ openclaw models auth order clear --provider anthropic
```
Verwenden Sie `--agent <id>`, um einen bestimmten Agenten anzusprechen; lassen Sie es weg, um den konfigurierten Standard-Agenten zu verwenden.
Wenn Sie Probleme mit der Reihenfolge debuggen, zeigt `openclaw models status --probe` ausgelassene gespeicherte Profile als `excluded_by_auth_order` an, statt sie stillschweigend zu überspringen.
Wenn Sie Probleme mit Abkühlzeiten debuggen, beachten Sie, dass Abkühlzeiten bei Rate Limits an eine einzelne Modell-ID statt an das gesamte Provider-Profil gebunden sein können.
Beim Debuggen von Problemen mit der Reihenfolge zeigt `openclaw models status --probe` ausgelassene
gespeicherte Profile als `excluded_by_auth_order` an, anstatt sie stillschweigend zu überspringen.
Beim Debuggen von Cooldown-Problemen sollten Sie beachten, dass Cooldowns für Rate-Limits
an eine einzelne Modell-ID statt an das gesamte Anbieterprofil gebunden sein können.
## Fehlerbehebung
### "No credentials found"
### „Keine Anmeldedaten gefunden“
Wenn das Anthropic-Profil fehlt, konfigurieren Sie auf dem **Gateway-Host** einen Anthropic-API-Schlüssel oder richten Sie den Anthropic-Setup-Token-Pfad ein und prüfen Sie dann erneut:
Wenn das Anthropic-Profil fehlt, konfigurieren Sie einen Anthropic-API-Schlüssel auf dem
**Gateway-Host** oder richten Sie den Anthropic-Setup-Token-Pfad ein und prüfen Sie dann erneut:
```bash
openclaw models status
@ -166,4 +205,6 @@ openclaw models status
### Token läuft bald ab/ist abgelaufen
Führen Sie `openclaw models status` aus, um zu bestätigen, welches Profil bald abläuft. Wenn ein Anthropic-Token-Profil fehlt oder abgelaufen ist, erneuern Sie diese Einrichtung über setup-token oder migrieren Sie zu einem Anthropic-API-Schlüssel.
Führen Sie `openclaw models status` aus, um zu bestätigen, welches Profil bald abläuft. Wenn ein
Anthropic-Token-Profil fehlt oder abgelaufen ist, aktualisieren Sie diese Einrichtung über
setup-token oder migrieren Sie zu einem Anthropic-API-Schlüssel.

198
docs/de/gateway/cli-backends.md
View File

@ -1,47 +1,47 @@
---
read_when:
- Sie möchten einen zuverlässigen Fallback, wenn API-Provider ausfallen
- Sie verwenden Codex CLI oder andere lokale AI CLIs und möchten sie wiederverwenden
- Sie möchten einen zuverlässigen Fallback, wenn API-Anbieter ausfallen
- Sie führen die Codex CLI oder andere lokale AI-CLIs aus und möchten sie wiederverwenden
- Sie möchten die MCP-Loopback-Bridge für den Tool-Zugriff des CLI-Backends verstehen
summary: 'CLI-Backends: lokaler AI-CLI-Fallback mit optionaler MCP-Tool-Bridge'
title: CLI-Backends
x-i18n:
generated_at: "2026-04-23T14:01:27Z"
generated_at: "2026-04-23T14:55:30Z"
model: gpt-5.4
provider: openai
source_hash: 475923b36e4580d3e4e57014ff2e6b89e9eb52c11b0a0ab1fc8241655b07836e
source_hash: ff7458d18b8a5b716930579241177917fd3edffcf7f6e211c7d570cf76519316
source_path: gateway/cli-backends.md
workflow: 15
---
# CLI-Backends (Fallback-Laufzeit)
OpenClaw kann **lokale AI CLIs** als **reinen Text-Fallback** ausführen, wenn API-Provider ausfallen,
rate-limitiert sind oder sich vorübergehend fehlerhaft verhalten. Das ist absichtlich konservativ:
OpenClaw kann **lokale AI-CLIs** als **reinen Text-Fallback** ausführen, wenn API-Anbieter ausgefallen sind,
rate-limitiert werden oder sich vorübergehend fehlerhaft verhalten. Das ist bewusst konservativ:
- **OpenClaw-Tools werden nicht direkt injiziert**, aber Backends mit `bundleMcp: true`
können Gateway-Tools über eine Loopback-MCP-Bridge erhalten.
- **JSONL-Streaming** für CLIs, die es unterstützen.
- **Sitzungen werden unterstützt** (damit Folgezüge kohärent bleiben).
- **Sitzungen werden unterstützt** (damit Folge-Turns konsistent bleiben).
- **Bilder können durchgereicht werden**, wenn die CLI Bildpfade akzeptiert.
Das ist als **Sicherheitsnetz** und nicht als primärer Pfad gedacht. Verwenden Sie es, wenn Sie
Das ist als **Sicherheitsnetz** statt als primärer Pfad gedacht. Verwenden Sie es, wenn Sie
„funktioniert immer“-Textantworten möchten, ohne sich auf externe APIs zu verlassen.
Wenn Sie eine vollständige Harness-Laufzeit mit ACP-Sitzungssteuerung, Hintergrundaufgaben,
Thread-/Konversationsbindung und persistenten externen Coding-Sitzungen möchten, verwenden Sie
stattdessen [ACP Agents](/de/tools/acp-agents). CLI-Backends sind kein ACP.
Wenn Sie eine vollständige Harness-Laufzeit mit ACP-Sitzungssteuerungen, Hintergrundaufgaben,
Thread-/Unterhaltungsbindung und persistenten externen Coding-Sitzungen möchten, verwenden Sie
stattdessen [ACP Agents](/de/tools/acp-agents). CLI-Backends sind nicht ACP.
## Einsteigerfreundlicher Schnellstart
Sie können Codex CLI **ohne Konfiguration** verwenden (das gebündelte OpenAI Plugin
Sie können die Codex CLI **ohne Konfiguration** verwenden (das gebündelte OpenAI-Plugin
registriert ein Standard-Backend):
```bash
openclaw agent --message "hi" --model codex-cli/gpt-5.4
```
Wenn Ihr Gateway unter launchd/systemd läuft und `PATH` minimal ist, fügen Sie nur den
Wenn Ihr Gateway unter launchd/systemd läuft und PATH minimal ist, fügen Sie nur den
Befehlspfad hinzu:
```json5
@ -60,14 +60,14 @@ Befehlspfad hinzu:
Das ist alles. Keine Schlüssel, keine zusätzliche Auth-Konfiguration außer der CLI selbst erforderlich.
Wenn Sie ein gebündeltes CLI-Backend als **primären Nachrichten-Provider** auf einem
Gateway-Host verwenden, lädt OpenClaw jetzt automatisch das besitzende gebündelte Plugin, wenn Ihre Konfiguration
dieses Backend explizit in einer Modellreferenz oder unter
Wenn Sie ein gebündeltes CLI-Backend als **primären Nachrichtenanbieter** auf einem
Gateway-Host verwenden, lädt OpenClaw jetzt automatisch das zugehörige gebündelte Plugin, wenn Ihre Konfiguration
dieses Backend explizit in einer Modell-Referenz oder unter
`agents.defaults.cliBackends` referenziert.
## Verwendung als Fallback
Fügen Sie Ihrer Fallback-Liste ein CLI-Backend hinzu, damit es nur ausgeführt wird, wenn primäre Modelle fehlschlagen:
Fügen Sie ein CLI-Backend zu Ihrer Fallback-Liste hinzu, damit es nur ausgeführt wird, wenn primäre Modelle fehlschlagen:
```json5
{
@ -88,11 +88,11 @@ Fügen Sie Ihrer Fallback-Liste ein CLI-Backend hinzu, damit es nur ausgeführt
Hinweise:
- Wenn Sie `agents.defaults.models` (Zulassungsliste) verwenden, müssen Sie dort auch Ihre CLI-Backend-Modelle aufnehmen.
- Wenn der primäre Provider fehlschlägt (Authentifizierung, Rate-Limits, Timeouts), versucht OpenClaw
- Wenn Sie `agents.defaults.models` (Allowlist) verwenden, müssen Sie dort auch Ihre CLI-Backend-Modelle einschließen.
- Wenn der primäre Anbieter fehlschlägt (Auth, Rate-Limits, Timeouts), versucht OpenClaw
als Nächstes das CLI-Backend.
## Konfigurationsübersicht
## Konfigurationsüberblick
Alle CLI-Backends befinden sich unter:
@ -100,8 +100,8 @@ Alle CLI-Backends befinden sich unter:
agents.defaults.cliBackends
```
Jeder Eintrag ist mit einer **Provider-ID** verschlüsselt (z. B. `codex-cli`, `my-cli`).
Die Provider-ID wird zur linken Seite Ihrer Modellreferenz:
Jeder Eintrag wird über eine **Anbieter-ID** verschlüsselt (z. B. `codex-cli`, `my-cli`).
Die Anbieter-ID wird zur linken Seite Ihrer Modell-Referenz:
```
<provider>/<model>
@ -147,69 +147,79 @@ Die Provider-ID wird zur linken Seite Ihrer Modellreferenz:
## Funktionsweise
1. **Wählt ein Backend aus** auf Basis des Provider-Präfixes (`codex-cli/...`).
2. **Erstellt einen System-Prompt** unter Verwendung desselben OpenClaw-Prompts und Workspace-Kontexts.
3. **Führt die CLI** mit einer Sitzungs-ID aus (falls unterstützt), damit der Verlauf konsistent bleibt.
Das gebündelte Backend `claude-cli` hält einen Claude-stdio-Prozess pro
OpenClaw-Sitzung am Leben und sendet Folgezüge über stream-json stdin.
1. **Wählt ein Backend aus** basierend auf dem Anbieterpräfix (`codex-cli/...`).
2. **Erstellt einen System-Prompt** mit demselben OpenClaw-Prompt und Workspace-Kontext.
3. **Führt die CLI aus** mit einer Sitzungs-ID (falls unterstützt), damit der Verlauf konsistent bleibt.
Das gebündelte `claude-cli`-Backend hält einen Claude-stdio-Prozess pro
OpenClaw-Sitzung am Leben und sendet Folge-Turns über stream-json-stdin.
4. **Parst die Ausgabe** (JSON oder Klartext) und gibt den endgültigen Text zurück.
5. **Persistiert Sitzungs-IDs** pro Backend, damit Folgezüge dieselbe CLI-Sitzung wiederverwenden.
5. **Persistiert Sitzungs-IDs** pro Backend, damit Folge-Turns dieselbe CLI-Sitzung wiederverwenden.
<Note>
Das gebündelte Anthropic-Backend `claude-cli` wird wieder unterstützt. Anthropic-Mitarbeiter
haben uns gesagt, dass die Claude-CLI-Nutzung im Stil von OpenClaw wieder erlaubt ist, daher behandelt OpenClaw
die Nutzung von `claude -p` für diese Integration als zulässig, sofern Anthropic
Das gebündelte Anthropic-`claude-cli`-Backend wird wieder unterstützt. Anthropic-Mitarbeiter
haben uns gesagt, dass die Verwendung der Claude CLI im OpenClaw-Stil wieder erlaubt ist, daher behandelt OpenClaw
die Nutzung von `claude -p` für diese Integration als genehmigt, sofern Anthropic
keine neue Richtlinie veröffentlicht.
</Note>
Das gebündelte OpenAI-Backend `codex-cli` leitet OpenClaws System-Prompt über
Codex' Konfigurationsüberschreibung `model_instructions_file` weiter (`-c
model_instructions_file="..."`). Codex stellt kein Flag im Claude-Stil
`--append-system-prompt` bereit, daher schreibt OpenClaw den zusammengesetzten Prompt für jede neue Codex-CLI-Sitzung in eine
Das gebündelte OpenAI-`codex-cli`-Backend reicht den System-Prompt von OpenClaw über
die Konfigurationsüberschreibung `model_instructions_file` von Codex weiter (`-c
model_instructions_file="..."`). Codex bietet kein Claude-ähnliches
Flag `--append-system-prompt`, daher schreibt OpenClaw den zusammengesetzten Prompt für jede neue Codex-CLI-Sitzung in eine
temporäre Datei.
Das gebündelte Anthropic-Backend `claude-cli` erhält den OpenClaw-Skills-Snapshot
Das gebündelte Anthropic-`claude-cli`-Backend erhält den OpenClaw-Skills-Snapshot
auf zwei Wegen: den kompakten OpenClaw-Skills-Katalog im angehängten System-Prompt und
ein temporäres Claude-Code-Plugin, das mit `--plugin-dir` übergeben wird. Das Plugin enthält
nur die für diesen Agenten/diese Sitzung zulässigen Skills, sodass Claudes nativer Skill-
Resolver dieselbe gefilterte Menge sieht, die OpenClaw sonst im Prompt bewerben würde.
Env-/API-Schlüssel-Überschreibungen für Skills werden von OpenClaw weiterhin auf die
Kindprozessumgebung für den Lauf angewendet.
ein temporäres Claude Code Plugin, das mit `--plugin-dir` übergeben wird. Das
Plugin enthält nur die geeigneten Skills für diesen Agenten bzw. diese Sitzung, sodass
der native Skill-Resolver von Claude Code dieselbe gefilterte Menge sieht, die OpenClaw sonst im
Prompt bekannt geben würde. Überschreibungen von Skill-Umgebungsvariablen/API-Schlüsseln werden weiterhin von OpenClaw auf die
Umgebung des untergeordneten Prozesses für den Lauf angewendet.
Bevor OpenClaw das gebündelte `claude-cli`-Backend verwenden kann, muss Claude Code selbst
bereits auf demselben Host angemeldet sein:
```bash
claude auth login
claude auth status --text
openclaw models auth login --provider anthropic --method cli --set-default
```
Verwenden Sie `agents.defaults.cliBackends.claude-cli.command` nur, wenn die Binärdatei `claude`
nicht bereits auf `PATH` liegt.
## Sitzungen
- Wenn die CLI Sitzungen unterstützt, setzen Sie `sessionArg` (z. B. `--session-id`) oder
`sessionArgs` (Platzhalter `{sessionId}`), wenn die ID in mehrere Flags eingefügt werden
muss.
`sessionArgs` (Platzhalter `{sessionId}`), wenn die ID in mehrere Flags eingefügt werden muss.
- Wenn die CLI einen **Resume-Unterbefehl** mit anderen Flags verwendet, setzen Sie
`resumeArgs` (ersetzt `args` beim Fortsetzen) und optional `resumeOutput`
(für Nicht-JSON-Fortsetzungen).
(für nicht-JSON-Resumes).
- `sessionMode`:
- `always`: immer eine Sitzungs-ID senden (neue UUID, wenn keine gespeichert ist).
- `existing`: nur dann eine Sitzungs-ID senden, wenn vorher eine gespeichert wurde.
- `existing`: nur eine Sitzungs-ID senden, wenn zuvor eine gespeichert wurde.
- `none`: niemals eine Sitzungs-ID senden.
- `claude-cli` verwendet standardmäßig `liveSession: "claude-stdio"`, `output: "jsonl"`
und `input: "stdin"`, sodass Folgezüge den laufenden Claude-Prozess wiederverwenden, während
er aktiv ist. Warmes stdio ist jetzt der Standard, auch bei benutzerdefinierten Konfigurationen,
die Transportfelder auslassen. Wenn das Gateway neu startet oder der Leerlaufprozess
beendet wird, setzt OpenClaw mit der gespeicherten Claude-Sitzungs-ID fort. Gespeicherte Sitzungs-
IDs werden vor dem Fortsetzen gegen ein vorhandenes lesbares Projekttranskript geprüft, sodass
Phantom-Bindungen mit `reason=transcript-missing` gelöscht werden, statt stillschweigend
eine neue Claude-CLI-Sitzung unter `--resume` zu starten.
- Gespeicherte CLI-Sitzungen sind Provider-eigene Kontinuität. Das implizite tägliche Zurücksetzen der Sitzung
unterbricht sie nicht; `/reset` und explizite Richtlinien `session.reset` tun es weiterhin.
- `claude-cli` verwendet standardmäßig `liveSession: "claude-stdio"`, `output: "jsonl"`,
und `input: "stdin"`, sodass Folge-Turns den laufenden Claude-Prozess wiederverwenden, solange
er aktiv ist. Warme stdio ist jetzt der Standard, auch für benutzerdefinierte Konfigurationen,
die Transportfelder auslassen. Wenn das Gateway neu startet oder der inaktive Prozess
beendet wird, setzt OpenClaw anhand der gespeicherten Claude-Sitzungs-ID fort. Gespeicherte Sitzungs-IDs
werden vor dem Fortsetzen gegen ein vorhandenes lesbares Projekt-Transkript geprüft, sodass
Phantom-Bindungen mit `reason=transcript-missing` gelöscht werden, anstatt stillschweigend eine neue Claude-CLI-Sitzung unter `--resume` zu starten.
- Gespeicherte CLI-Sitzungen sind anbietereigene Kontinuität. Der implizite tägliche Sitzungs-
reset unterbricht sie nicht; `/reset` und explizite `session.reset`-Richtlinien schon.
Hinweise zur Serialisierung:
- `serialize: true` hält Läufe in derselben Lane geordnet.
- Die meisten CLIs serialisieren auf einer Provider-Lane.
- Die meisten CLIs serialisieren auf einer Anbieter-Lane.
- OpenClaw verwirft die Wiederverwendung gespeicherter CLI-Sitzungen, wenn sich die ausgewählte Auth-Identität ändert,
einschließlich einer geänderten Auth-Profil-ID, eines statischen API-Schlüssels, eines statischen Tokens oder der OAuth-
Kontenidentität, wenn die CLI eine solche bereitstellt. Die Rotation von OAuth-Zugriffs- und Refresh-Tokens
unterbricht die gespeicherte CLI-Sitzung nicht. Wenn eine CLI keine stabile OAuth-Konto-ID bereitstellt,
lässt OpenClaw diese CLI die Resume-Berechtigungen selbst durchsetzen.
Kontoidentität, wenn die CLI eine solche bereitstellt. Die Rotation von OAuth-Zugriffs- und Refresh-Tokens
unterbricht die gespeicherte CLI-Sitzung nicht. Wenn eine CLI keine stabile OAuth-Konto-ID offenlegt,
überlässt OpenClaw dieser CLI die Durchsetzung der Fortsetzungsberechtigungen.
## Bilder (Durchreichung)
## Bilder (Pass-through)
Wenn Ihre CLI Bildpfade akzeptiert, setzen Sie `imageArg`:
@ -221,15 +231,15 @@ imageMode: "repeat"
OpenClaw schreibt Base64-Bilder in temporäre Dateien. Wenn `imageArg` gesetzt ist, werden diese
Pfade als CLI-Argumente übergeben. Wenn `imageArg` fehlt, hängt OpenClaw die
Dateipfade an den Prompt an (Pfadinjektion), was für CLIs ausreicht, die lokale
Dateien automatisch aus einfachen Pfaden laden.
Dateien aus reinen Pfaden automatisch laden.
## Eingaben / Ausgaben
## Ein- / Ausgaben
- `output: "json"` (Standard) versucht, JSON zu parsen und Text + Sitzungs-ID zu extrahieren.
- Für die Gemini-CLI-JSON-Ausgabe liest OpenClaw Antworttext aus `response` und
- Für die JSON-Ausgabe der Gemini CLI liest OpenClaw Antworttext aus `response` und
Nutzung aus `stats`, wenn `usage` fehlt oder leer ist.
- `output: "jsonl"` parst JSONL-Streams (zum Beispiel Codex CLI `--json`) und extrahiert die endgültige Agentennachricht sowie Sitzungs-
Kennungen, wenn vorhanden.
- `output: "jsonl"` parst JSONL-Streams (zum Beispiel Codex CLI `--json`) und extrahiert die endgültige Agenten-Nachricht sowie Sitzungs-
kennungen, wenn vorhanden.
- `output: "text"` behandelt stdout als endgültige Antwort.
Eingabemodi:
@ -240,7 +250,7 @@ Eingabemodi:
## Standardwerte (Plugin-eigen)
Das gebündelte OpenAI Plugin registriert auch einen Standardwert für `codex-cli`:
Das gebündelte OpenAI-Plugin registriert auch einen Standardwert für `codex-cli`:
- `command: "codex"`
- `args: ["exec","--json","--color","never","--sandbox","workspace-write","--skip-git-repo-check"]`
@ -251,7 +261,7 @@ Das gebündelte OpenAI Plugin registriert auch einen Standardwert für `codex-cl
- `imageArg: "--image"`
- `sessionMode: "existing"`
Das gebündelte Google Plugin registriert auch einen Standardwert für `google-gemini-cli`:
Das gebündelte Google-Plugin registriert auch einen Standardwert für `google-gemini-cli`:
- `command: "gemini"`
- `args: ["--output-format", "json", "--prompt", "{prompt}"]`
@ -263,31 +273,31 @@ Das gebündelte Google Plugin registriert auch einen Standardwert für `google-g
- `sessionIdFields: ["session_id", "sessionId"]`
Voraussetzung: Die lokale Gemini CLI muss installiert und als
`gemini` in `PATH` verfügbar sein (`brew install gemini-cli` oder
`gemini` auf `PATH` verfügbar sein (`brew install gemini-cli` oder
`npm install -g @google/gemini-cli`).
Hinweise zu Gemini-CLI-JSON:
- Antworttext wird aus dem JSON-Feld `response` gelesen.
- Nutzung fällt auf `stats` zurück, wenn `usage` fehlt oder leer ist.
- Die Nutzung greift auf `stats` zurück, wenn `usage` fehlt oder leer ist.
- `stats.cached` wird in OpenClaw `cacheRead` normalisiert.
- Wenn `stats.input` fehlt, leitet OpenClaw Eingabetokens aus
- Wenn `stats.input` fehlt, leitet OpenClaw Eingabetoken aus
`stats.input_tokens - stats.cached` ab.
Überschreiben Sie nur bei Bedarf (üblich: absoluter `command`-Pfad).
Nur bei Bedarf überschreiben (häufig: absoluter `command`-Pfad).
## Plugin-eigene Standardwerte
Standardwerte für CLI-Backends sind jetzt Teil der Plugin-Oberfläche:
CLI-Backend-Standardwerte sind jetzt Teil der Plugin-Oberfläche:
- Plugins registrieren sie mit `api.registerCliBackend(...)`.
- Die Backend-`id` wird zum Provider-Präfix in Modellreferenzen.
- Die Benutzerkonfiguration in `agents.defaults.cliBackends.<id>` überschreibt weiterhin den Plugin-Standard.
- Backend-spezifische Konfigurationsbereinigung bleibt über den optionalen
Hook `normalizeConfig` im Besitz des Plugins.
- Die Backend-`id` wird zum Anbieterpräfix in Modell-Referenzen.
- Die Benutzerkonfiguration in `agents.defaults.cliBackends.<id>` überschreibt weiterhin den Plugin-Standardwert.
- Das backend-spezifische Bereinigen der Konfiguration bleibt über den optionalen
Hook `normalizeConfig` plugin-eigen.
Plugins, die kleine Kompatibilitätsshims für Prompt/Nachrichten benötigen, können
bidirektionale Texttransformationen deklarieren, ohne einen Provider oder ein CLI-Backend zu ersetzen:
Plugins, die kleine Kompatibilitäts-Shims für Prompt/Nachrichten benötigen, können
bidirektionale Texttransformationen deklarieren, ohne einen Anbieter oder ein CLI-Backend zu ersetzen:
```typescript
api.registerTextTransforms({
@ -305,16 +315,16 @@ api.registerTextTransforms({
```
`input` schreibt den System-Prompt und den Benutzer-Prompt um, die an die CLI übergeben werden. `output`
schreibt gestreamte Assistant-Deltas und geparsten Endtext um, bevor OpenClaw
seine eigenen Kontrollmarker und die Kanalzustellung verarbeitet.
schreibt gestreamte Assistant-Deltas und den geparsten Endtext um, bevor OpenClaw
seine eigenen Kontrollmarker und die Kanalauslieferung verarbeitet.
Für CLIs, die JSONL im Format Claude Code stream-json-kompatibel ausgeben, setzen Sie
Für CLIs, die mit Claude Code stream-json kompatibles JSONL ausgeben, setzen Sie
`jsonlDialect: "claude-stream-json"` in der Konfiguration dieses Backends.
## Bundle-MCP-Overlays
CLI-Backends erhalten **keine** direkten OpenClaw-Tool-Aufrufe, aber ein Backend kann
sich mit `bundleMcp: true` für ein generiertes MCP-Konfigurations-Overlay entscheiden.
CLI-Backends erhalten **keine** OpenClaw-Tool-Aufrufe direkt, aber ein Backend kann sich
mit `bundleMcp: true` für ein generiertes MCP-Konfigurations-Overlay anmelden.
Aktuelles gebündeltes Verhalten:
@ -324,26 +334,26 @@ Aktuelles gebündeltes Verhalten:
Wenn Bundle MCP aktiviert ist, führt OpenClaw Folgendes aus:
- Startet einen Loopback-HTTP-MCP-Server, der Gateway-Tools dem CLI-Prozess bereitstellt
- startet einen HTTP-Loopback-MCP-Server, der Gateway-Tools für den CLI-Prozess bereitstellt
- authentifiziert die Bridge mit einem Token pro Sitzung (`OPENCLAW_MCP_TOKEN`)
- begrenzt den Tool-Zugriff auf die aktuelle Sitzung, das aktuelle Konto und den aktuellen Kanalkontext
- begrenzt den Tool-Zugriff auf die aktuelle Sitzung, das Konto und den Kanalkontext
- lädt aktivierte Bundle-MCP-Server für den aktuellen Workspace
- führt sie mit jeder vorhandenen MCP-Konfigurations-/Einstellungsform des Backends zusammen
- schreibt die Startkonfiguration mit dem backend-eigenen Integrationsmodus aus der besitzenden Extension um
- führt sie mit einer vorhandenen MCP-Konfigurations-/Einstellungsstruktur des Backends zusammen
- schreibt die Startkonfiguration mithilfe des backend-eigenen Integrationsmodus aus der zugehörigen Erweiterung um
Wenn keine MCP-Server aktiviert sind, injiziert OpenClaw trotzdem eine strikte Konfiguration, wenn sich ein
Backend für Bundle MCP entscheidet, damit Hintergrundläufe isoliert bleiben.
Wenn keine MCP-Server aktiviert sind, injiziert OpenClaw dennoch eine strikte Konfiguration, wenn sich ein
Backend für Bundle MCP anmeldet, damit Hintergrundläufe isoliert bleiben.
## Einschränkungen
- **Keine direkten OpenClaw-Tool-Aufrufe.** OpenClaw injiziert keine Tool-Aufrufe in
das CLI-Backend-Protokoll. Backends sehen Gateway-Tools nur dann, wenn sie sich für
`bundleMcp: true` entscheiden.
das CLI-Backend-Protokoll. Backends sehen Gateway-Tools nur, wenn sie sich für
`bundleMcp: true` anmelden.
- **Streaming ist backend-spezifisch.** Einige Backends streamen JSONL; andere puffern
bis zum Beenden.
- **Strukturierte Ausgaben** hängen vom JSON-Format der CLI ab.
- **Codex-CLI-Sitzungen** werden über Textausgabe fortgesetzt (kein JSONL), was weniger
strukturiert ist als der anfängliche Lauf mit `--json`. OpenClaw-Sitzungen funktionieren trotzdem
- **Codex-CLI-Sitzungen** werden über Textausgabe fortgesetzt (ohne JSONL), was weniger
strukturiert ist als der ursprüngliche Lauf mit `--json`. OpenClaw-Sitzungen funktionieren weiterhin
normal.
## Fehlerbehebung
@ -351,5 +361,5 @@ Backend für Bundle MCP entscheidet, damit Hintergrundläufe isoliert bleiben.
- **CLI nicht gefunden**: Setzen Sie `command` auf einen vollständigen Pfad.
- **Falscher Modellname**: Verwenden Sie `modelAliases`, um `provider/model` → CLI-Modell zuzuordnen.
- **Keine Sitzungskontinuität**: Stellen Sie sicher, dass `sessionArg` gesetzt ist und `sessionMode` nicht
`none` ist (Codex CLI kann derzeit nicht mit JSON-Ausgabe fortsetzen).
`none` ist (die Codex CLI kann derzeit nicht mit JSON-Ausgabe fortsetzen).
- **Bilder werden ignoriert**: Setzen Sie `imageArg` (und prüfen Sie, ob die CLI Dateipfade unterstützt).

979
docs/de/help/testing.md
View File

File diff suppressed because it is too large Load Diff