На цій сторінці
На цій сторінці
CLI commands
Конфігурація
Неінтерактивні допоміжні команди для openclaw.json: отримати/встановити/накласти латки/скасувати значення за шляхом, вивести схему, перевірити або вивести шлях до активного файлу. Запустіть openclaw config без підкоманди, щоб відкрити той самий покроковий майстер, що й openclaw configure.
Кореневі параметри
--section <section>stringПовторюваний фільтр розділів покрокового налаштування під час запуску openclaw config без підкоманди.
Розділи покрокового налаштування: workspace, model, web, gateway, daemon, channels, plugins, skills, health.
Приклади
Шляхи
Крапкова нотація або нотація з дужками. У прикладах для оболонки беріть шляхи з дужками в лапки, щоб zsh не розгортав [0] як шаблон:
config get
Зчитує значення з редагованого знімка конфігурації (секрети ніколи не виводяться). --json виводить необроблене значення у форматі JSON; інакше рядки, числа й логічні значення виводяться без оформлення, а об’єкти та масиви — як форматований JSON.
config file
Виводить шлях до активного файлу конфігурації, визначений із OPENCLAW_CONFIG_PATH або стандартного розташування. Шлях указує на звичайний файл, а не на символічне посилання; див. Безпека запису.
config schema
Виводить згенеровану схему JSON для openclaw.json у стандартний потік виведення.
Що вона містить
- Поточна коренева схема конфігурації та кореневе рядкове поле
$schemaдля інструментів редактора. - Метадані документації полів
title/description, які використовує інтерфейс керування. - Вкладені об’єкти, вузли з шаблоном (
*) і вузли елементів масиву ([]) успадковують ті самі метаданіtitle/description, якщо існує відповідна документація полів. - Гілки
anyOf/oneOf/allOfтакож успадковують ті самі метадані документації. - Метадані схеми активних плагінів і каналів за принципом максимально можливих зусиль, коли можна завантажити маніфести середовища виконання.
- Чиста резервна схема, навіть якщо поточна конфігурація недійсна.
Пов’язаний RPC середовища виконання
config.schema.lookup повертає один нормалізований шлях конфігурації з поверхневим вузлом схеми (title, description, type, enum, const, загальні обмеження), відповідними метаданими підказок інтерфейсу та зведеннями безпосередніх дочірніх елементів. Використовуйте його для деталізації в межах шляху в інтерфейсі керування або власних клієнтах.
config validate
Перевіряє поточну конфігурацію за активною схемою без запуску gateway.
Значення
Значення за можливості аналізуються як JSON5; інакше вони вважаються необробленими рядками. Використовуйте --strict-json, щоб вимагати стандартний JSON без резервного трактування як рядка (у такому разі синтаксис, властивий лише JSON5, як-от коментарі, кінцеві коми або ключі без лапок, відхиляється). --json — застарілий псевдонім для --strict-json у config set.
config get <path> --json виводить необроблене значення у форматі JSON замість тексту, відформатованого для термінала.
Під час додавання записів до цих мап використовуйте --merge:
Використовуйте --replace лише тоді, коли надане значення має навмисно стати повним цільовим значенням.
Режими config set
Режим значення
Режим конструктора SecretRef
Режим конструктора постачальника
Лише для шляхів secrets.providers.<alias>:
Пакетний режим
Пакетний аналіз завжди використовує пакетне корисне навантаження (--batch-json/--batch-file) як джерело істини; --strict-json / --json не змінюють поведінку пакетного аналізу.
Режим шляху/значення JSON також працює безпосередньо для SecretRef і постачальників:
Прапорці конструктора постачальника
Цілі конструктора постачальника мають використовувати secrets.providers.<alias> як шлях.
Загальні прапорці
--provider-source <env|file|exec>--provider-timeout-ms <ms>(file,exec)
Постачальник середовища (--provider-source env)
--provider-allowlist <ENV_VAR>(можна повторювати)
Файловий постачальник (--provider-source file)
--provider-path <path>(обов’язково)--provider-mode <singleValue|json>--provider-max-bytes <bytes>--provider-allow-insecure-path
Постачальник виконання (--provider-source exec)
--provider-command <path>(обов’язково)--provider-arg <arg>(можна повторювати)--provider-no-output-timeout-ms <ms>--provider-max-output-bytes <bytes>--provider-json-only--provider-env <KEY=VALUE>(можна повторювати)--provider-pass-env <ENV_VAR>(можна повторювати)--provider-trusted-dir <path>(можна повторювати)--provider-allow-insecure-path--provider-allow-symlink-command
Приклад посиленого постачальника виконання:
config patch
Вставте або передайте через канал конфігураційну латку JSON5 замість виконання багатьох команд config set на основі шляхів. Об’єкти об’єднуються рекурсивно; масиви та скалярні значення замінюють ціль; null видаляє цільовий шлях.
Передайте латку через стандартний ввід для сценаріїв віддаленого налаштування:
Приклад латки:
Використовуйте --replace-path <path>, коли один об’єкт або масив має стати точно наданим значенням замість рекурсивного накладання латки:
--dry-run виконує перевірки схеми й можливості розв’язання SecretRef без запису. Під час пробного запуску SecretRef на основі виконуваних команд типово пропускаються; додайте --allow-exec, якщо навмисно хочете, щоб пробний запуск виконував команди постачальника.
Пробний запуск
--dry-run перевіряє зміни без запису openclaw.json. Доступно для config set, config patch і config unset.
Поведінка пробного запуску
- Режим конструктора: виконує перевірки можливості розв’язання SecretRef для змінених посилань/провайдерів.
- Режим JSON (
--strict-json,--jsonабо пакетний режим): виконує перевірку схеми та можливості розв’язання SecretRef. - Перевірка політики виконується для повної конфігурації після змін, тому запис батьківського об’єкта (наприклад, установлення
hooksяк об’єкта) не дає змоги обійти перевірку непідтримуваної поверхні. - Перевірки Exec SecretRef типово пропускаються, щоб уникнути побічних ефектів команд; передайте
--allow-exec, щоб увімкнути їх (це може виконати команди провайдера).--allow-execпризначено лише для пробного запуску; без--dry-runвиникає помилка.
Поля --dry-run --json
ok: чи успішно пройшов пробний запускoperations: кількість оцінених присвоєньchecks: чи виконувалися перевірки схеми/можливості розв’язанняchecks.resolvabilityComplete: чи перевірки можливості розв’язання завершилися повністю (false, коли посилання exec пропущено)refsChecked: кількість посилань, фактично розв’язаних під час пробного запускуskippedExecRefs: кількість посилань exec, пропущених через те, що--allow-execне було встановленоerrors: структуровані помилки відсутнього шляху, схеми або можливості розв’язання, колиok=false
Структура виводу JSON
Приклад успішного виконання
Приклад невдалого виконання
Якщо пробний запуск завершився невдало
config schema validation failed: структура конфігурації після змін недійсна; виправте шлях/значення або структуру об’єкта провайдера/посилання.Config policy validation failed: unsupported SecretRef usage: поверніть ці облікові дані до введення у вигляді звичайного тексту/рядка; використовуйте SecretRef лише на підтримуваних поверхнях.SecretRef assignment(s) could not be resolved: указаний провайдер/посилання наразі неможливо розв’язати (відсутня змінна середовища, недійсний вказівник на файл, помилка провайдера exec або невідповідність провайдера/джерела).Dry run note: skipped <n> exec SecretRef resolvability check(s): повторно запустіть із--allow-exec, якщо потрібно перевірити можливість розв’язання exec.- У пакетному режимі виправте записи з помилками та повторно запустіть
--dry-runперед записом.
Застосування змін
Після кожного успішного виконання config set / config patch / config unset CLI виводить одну з трьох підказок, щоб було зрозуміло, чи потрібно перезапустити Gateway:
| Підказка | Значення |
|---|---|
Restart the gateway to apply. |
Змінений шлях потребує повного перезапуску. |
Change will apply without restarting the gateway. |
Гаряче перезавантаження застосує його автоматично. |
No gateway restart needed. |
Нічого важливого для середовища виконання не змінилося. |
Запис до plugins.entries (або будь-якого вкладеного шляху) завжди потребує перезапуску, оскільки CLI не може підтвердити, що завантажено метадані перезавантаження кожного плагіна.
Безпека запису
openclaw config set та інші засоби запису конфігурації, що належать OpenClaw, перевіряють повну конфігурацію після змін перед її збереженням на диск. Якщо нове корисне навантаження не проходить перевірку схеми або схоже на руйнівне перезаписування, активна конфігурація залишається незмінною, а відхилене корисне навантаження зберігається поруч як openclaw.json.rejected.*.
Під час запису засоби OpenClaw повторно серіалізують JSON5 як стандартний JSON. Якщо джерело містить коментарі, засіб запису попереджає безпосередньо перед їх видаленням; використовуйте текстовий редактор безпосередньо, якщо важливо зберегти коментарі.
Для невеликих змін надавайте перевагу запису через CLI:
Якщо запис відхилено, перевірте збережене корисне навантаження та виправте повну структуру конфігурації:
Безпосереднє редагування в текстовому редакторі також дозволено, але запущений Gateway вважає такі зміни ненадійними, доки вони не пройдуть перевірку. Недійсні безпосередні зміни спричиняють помилку запуску або пропускаються під час гарячого перезавантаження; Gateway не перезаписує openclaw.json. Запустіть openclaw doctor --fix, щоб відновити конфігурацію з префіксом або руйнівно перезаписану конфігурацію чи повернути останню відому справну копію. Див. Усунення несправностей Gateway.
Відновлення всього файлу призначене лише для виправлення за допомогою doctor. Зміни схеми плагіна або розбіжність minHostVersion спричиняють явну помилку замість відкочування непов’язаних налаштувань користувача, як-от конфігурація моделей, провайдерів, профілів автентифікації, каналів, доступності Gateway, інструментів, пам’яті, браузера або cron.
Цикл виправлення
Після успішного виконання openclaw config validate скористайтеся локальним TUI, щоб вбудований агент порівняв активну конфігурацію з документацією, поки ви перевірятимете кожну зміну в тому самому терміналі:
У TUI початковий ! запускає буквальну локальну команду оболонки (після одноразового запиту підтвердження для кожного сеансу):
Порівняйте з документацією
Попросіть агента порівняти поточну конфігурацію з відповідною сторінкою документації та запропонувати найменше виправлення.
Застосуйте цільові зміни
Застосуйте цільові зміни за допомогою openclaw config set або openclaw configure.
Повторно перевірте
Повторно запускайте openclaw config validate після кожної зміни.
Doctor для проблем середовища виконання
Якщо перевірка проходить успішно, але середовище виконання все ще несправне, запустіть openclaw doctor або openclaw doctor --fix, щоб отримати допомогу з міграцією та виправленням.