openclaw config
Konfigurationshilfen für nicht interaktive Bearbeitungen in openclaw.json: Werte per Pfad mit get/set/unset/file/schema/validate
lesen, setzen oder entfernen und die aktive Konfigurationsdatei ausgeben. Ohne Subcommand ausgeführt,
wird der Konfigurationsassistent geöffnet (wie bei openclaw configure).
Root-Optionen:
--section <section>: wiederholbarer Abschnittsfilter für die geführte Einrichtung, wenn Sieopenclaw configohne Subcommand ausführen
workspacemodelwebgatewaydaemonchannelspluginsskillshealth
Beispiele
config schema
Gibt das generierte JSON-Schema für openclaw.json als JSON auf stdout aus.
Was es enthält:
- Das aktuelle Root-Konfigurationsschema sowie ein Root-String-Feld
$schemafür Editor-Tooling - Dokumentationsmetadaten
titleunddescription, die von der Control UI verwendet werden - Verschachtelte Objekte, Wildcard-Knoten (
*) und Array-Elementknoten ([]) übernehmen dieselben Metadatentitle/description, wenn passende Felddokumentation vorhanden ist - Auch Zweige mit
anyOf/oneOf/allOfübernehmen dieselben Dokumentationsmetadaten, wenn passende Felddokumentation vorhanden ist - Best-Effort-Live-Metadaten für Plugin- + Kanal-Schemas, wenn Runtime-Manifeste geladen werden können
- Ein sauberes Fallback-Schema, selbst wenn die aktuelle Konfiguration ungültig ist
config.schema.lookupgibt einen normalisierten Konfigurationspfad mit einem flachen Schemaknoten (title,description,type,enum,const, allgemeine Grenzen), passenden UI-Hinweismetadaten und Zusammenfassungen der direkten untergeordneten Elemente zurück. Verwenden Sie dies für pfadbezogenes Drill-down in der Control UI oder in benutzerdefinierten Clients.
Pfade
Pfade verwenden Punkt- oder Klammernotation:Werte
Werte werden nach Möglichkeit als JSON5 geparst, andernfalls als Strings behandelt. Verwenden Sie--strict-json, um JSON5-Parsing zu erzwingen. --json wird weiterhin als Legacy-Alias unterstützt.
config get <path> --json gibt den Rohwert als JSON statt als terminalformatierter Text aus.
Modi von config set
openclaw config set unterstützt vier Zuweisungsarten:
- Wertmodus:
openclaw config set <path> <value> - SecretRef-Builder-Modus:
- Provider-Builder-Modus (nur für den Pfad
secrets.providers.<alias>):
- Batch-Modus (
--batch-jsonoder--batch-file):
- SecretRef-Zuweisungen werden auf nicht unterstützten, zur Laufzeit veränderbaren Oberflächen abgelehnt (zum Beispiel
hooks.token,commands.ownerDisplaySecret, Discord-Webhook-Tokens für Thread-Bindings und WhatsApp-Creds-JSON). Siehe SecretRef Credential Surface.
--batch-json/--batch-file) als Quelle der Wahrheit.
--strict-json / --json ändern das Verhalten des Batch-Parsings nicht.
Der JSON-Pfad-/Wertmodus bleibt sowohl für SecretRefs als auch für Provider unterstützt:
Provider-Builder-Flags
Ziele des Provider-Builders müssensecrets.providers.<alias> als Pfad verwenden.
Gemeinsame Flags:
--provider-source <env|file|exec>--provider-timeout-ms <ms>(file,exec)
--provider-source env):
--provider-allowlist <ENV_VAR>(wiederholbar)
--provider-source file):
--provider-path <path>(erforderlich)--provider-mode <singleValue|json>--provider-max-bytes <bytes>
--provider-source exec):
--provider-command <path>(erforderlich)--provider-arg <arg>(wiederholbar)--provider-no-output-timeout-ms <ms>--provider-max-output-bytes <bytes>--provider-json-only--provider-env <KEY=VALUE>(wiederholbar)--provider-pass-env <ENV_VAR>(wiederholbar)--provider-trusted-dir <path>(wiederholbar)--provider-allow-insecure-path--provider-allow-symlink-command
Dry Run
Verwenden Sie--dry-run, um Änderungen zu validieren, ohne openclaw.json zu schreiben.
- Builder-Modus: führt SecretRef-Auflösbarkeitsprüfungen für geänderte Refs/Provider aus.
- JSON-Modus (
--strict-json,--jsonoder Batch-Modus): führt Schemaprüfung plus SecretRef-Auflösbarkeitsprüfungen aus. - Richtlinienvalidierung wird ebenfalls für bekannte nicht unterstützte SecretRef-Zieloberflächen ausgeführt.
- Richtlinienprüfungen bewerten die vollständige Konfiguration nach der Änderung, sodass Schreibvorgänge auf Elternobjektebene (zum Beispiel das Setzen von
hooksals Objekt) die Validierung nicht unterstützter Oberflächen nicht umgehen können. - Exec-SecretRef-Prüfungen werden standardmäßig während Dry Run übersprungen, um Nebeneffekte von Befehlen zu vermeiden.
- Verwenden Sie
--allow-execzusammen mit--dry-run, um Exec-SecretRef-Prüfungen zu aktivieren (dies kann Provider-Befehle ausführen). --allow-execgilt nur für Dry Run und erzeugt einen Fehler, wenn es ohne--dry-runverwendet wird.
--dry-run --json gibt einen maschinenlesbaren Bericht aus:
ok: ob der Dry Run erfolgreich waroperations: Anzahl der ausgewerteten Zuweisungenchecks: ob Schema-/Auflösbarkeitsprüfungen ausgeführt wurdenchecks.resolvabilityComplete: ob Auflösbarkeitsprüfungen vollständig ausgeführt wurden (false, wenn Exec-Refs übersprungen werden)refsChecked: Anzahl der Refs, die während Dry Run tatsächlich aufgelöst wurdenskippedExecRefs: Anzahl der Exec-Refs, die übersprungen wurden, weil--allow-execnicht gesetzt warerrors: strukturierte Schema-/Auflösbarkeitsfehler, wennok=false
Form der JSON-Ausgabe
config schema validation failed: Die Form Ihrer Konfiguration nach der Änderung ist ungültig; korrigieren Sie Pfad/Wert oder die Form des Provider-/Ref-Objekts.Config policy validation failed: unsupported SecretRef usage: Verschieben Sie diese Anmeldedaten zurück zu Klartext-/String-Eingaben und verwenden Sie SecretRefs nur auf unterstützten Oberflächen.SecretRef assignment(s) could not be resolved: Der referenzierte Provider/Ref kann derzeit nicht aufgelöst werden (fehlende Env var, ungültiger Dateizeiger, Fehler im Exec-Provider oder Provider-/Quellen-Mismatch).Dry run note: skipped <n> exec SecretRef resolvability check(s): Dry Run hat Exec-Refs übersprungen; führen Sie ihn mit--allow-execerneut aus, wenn Sie die Auflösbarkeit von Exec prüfen müssen.- Im Batch-Modus: Korrigieren Sie die fehlschlagenden Einträge und führen Sie
--dry-runerneut aus, bevor Sie schreiben.
Subcommands
config file: Gibt den aktiven Pfad der Konfigurationsdatei aus (aufgelöst ausOPENCLAW_CONFIG_PATHoder dem Standardpfad).