Skip to main content
OpenClaw читає необов’язкову конфігурацію з ~/.openclaw/openclaw.json. Якщо файл відсутній, OpenClaw використовує безпечні стандартні значення. Шлях активної конфігурації має вказувати на звичайний файл. Під час запису OpenClaw атомарно замінює його (перейменовує файл у цей шлях), тому для openclaw.json, що є символічним посиланням, буде замінено цільовий файл, а не виконано наскрізний запис — уникайте конфігурацій із символічними посиланнями. Якщо конфігурація зберігається поза стандартним каталогом стану, спрямуйте OPENCLAW_CONFIG_PATH безпосередньо на фактичний файл. Поширені причини додати конфігурацію:
  • Підключити канали та визначити, хто може надсилати повідомлення боту
  • Налаштувати моделі, інструменти, ізоляцію або автоматизацію (cron, хуки)
  • Налаштувати сеанси, медіа, мережу або інтерфейс користувача
Опис усіх доступних полів див. у повному довіднику. Агенти й автоматизація мають використовувати config.schema.lookup, щоб отримувати точну документацію на рівні полів перед редагуванням конфігурації. Використовуйте цю сторінку для практичних вказівок, а Довідник із конфігурації — для ширшої карти полів і стандартних значень.
Уперше налаштовуєте конфігурацію? Почніть з openclaw onboard для інтерактивного налаштування або перегляньте посібник Приклади конфігурації із готовими конфігураціями для копіювання та вставлення.

Мінімальна конфігурація

Редагування конфігурації

Сувора перевірка

OpenClaw приймає лише конфігурації, які повністю відповідають схемі. Невідомі ключі, некоректні типи або недійсні значення змушують Gateway відмовитися від запуску. Єдиний виняток на кореневому рівні — $schema (рядок), щоб редактори могли додавати метадані JSON Schema.
openclaw config schema виводить канонічну JSON Schema, яку використовують інтерфейс керування та перевірка. config.schema.lookup отримує один вузол для заданого шляху та зведення дочірніх вузлів для інструментів деталізації. Метадані документації полів title/description поширюються на вкладені об’єкти, гілки із символом узагальнення (*), елементами масиву ([]) та anyOf/ oneOf/allOf. Схеми плагінів і каналів середовища виконання об’єднуються після завантаження реєстру маніфестів. Якщо перевірка завершується невдало:
  • Gateway не запускається
  • Працюють лише діагностичні команди (openclaw doctor, openclaw logs, openclaw health, openclaw status)
  • Виконайте openclaw doctor, щоб переглянути точний перелік проблем
  • Виконайте openclaw doctor --fix (--repair — той самий прапорець; --yes пропускає запити підтвердження), щоб застосувати виправлення
Після кожного успішного запуску Gateway зберігає надійну останню відому справну копію, але запуск і гаряче перезавантаження не відновлюють її автоматично — це робить лише openclaw doctor --fix. Якщо openclaw.json не проходить перевірку (включно з локальною перевіркою плагіна), запуск Gateway завершується невдало або перезавантаження пропускається, а поточне середовище виконання зберігає останню прийняту конфігурацію. Відхилений запис також зберігається як <path>.rejected.<timestamp> для перевірки. Gateway блокує записи, схожі на випадкове затирання даних: видалення gateway.mode, втрату блоку meta або зменшення файлу більш ніж удвічі — якщо запис явно не дозволяє руйнівні зміни. Перенесення до останньої відомої справної копії пропускається, якщо кандидат містить заповнювач прихованого секрету, як-от *** або [redacted].

Поширені завдання

Кожен канал має власний розділ конфігурації в channels.<provider>. Кроки налаштування див. на спеціальній сторінці відповідного каналу:Усі канали використовують однаковий шаблон політики особистих повідомлень:
Задайте основну модель і необов’язкові резервні моделі:
  • agents.defaults.models визначає каталог моделей і слугує списком дозволених значень для /model; записи provider/* фільтрують /model, /models та засоби вибору моделей до вибраних постачальників, водночас і надалі використовуючи динамічне виявлення моделей.
  • Використовуйте openclaw config set agents.defaults.models '<json>' --strict-json --merge, щоб додавати записи до списку дозволених, не видаляючи наявні моделі. Звичайні заміни, які видалили б записи, відхиляються, якщо не передати --replace.
  • Посилання на моделі використовують формат provider/model (наприклад, anthropic/claude-opus-4-6).
  • agents.defaults.imageMaxDimensionPx керує зменшенням розміру зображень у транскриптах та інструментах (стандартне значення — 1200); менші значення зазвичай скорочують використання токенів комп’ютерного зору під час запусків із великою кількістю знімків екрана.
  • Відомості про перемикання моделей у чаті див. у CLI моделей, а про ротацію автентифікації та поведінку резервних моделей — у Перемиканні моделей у разі відмови.
  • Відомості про власних або самостійно розміщених постачальників див. у розділі Власні постачальники довідника.
Доступ до особистих повідомлень контролюється окремо для кожного каналу через dmPolicy (стандартне значення — "pairing"):
  • "pairing": невідомі відправники отримують одноразовий код сполучення для схвалення
  • "allowlist": дозволено лише відправникам із allowFrom (або зі сховища дозволених сполучених відправників)
  • "open": дозволити всі вхідні особисті повідомлення (потребує allowFrom: ["*"])
  • "disabled": ігнорувати всі особисті повідомлення
Для груп використовуйте groupPolicy ("allowlist" | "open" | "disabled") разом із groupAllowFrom або списками дозволених значень для конкретних каналів.Докладні відомості для кожного каналу див. у повному довіднику.
За замовчуванням групові повідомлення потребують згадки. Налаштуйте шаблони активації для кожного агента. Звичайні відповіді в групах і каналах надсилаються автоматично; увімкніть шлях через інструмент повідомлень для спільних кімнат, де агент має вирішувати, коли відповідати:
  • Згадки в метаданих: нативні @-згадки (торкніться для згадки у WhatsApp, @bot у Telegram тощо)
  • Текстові шаблони: безпечні шаблони регулярних виразів у mentionPatterns
  • Видимі відповіді: messages.visibleReplies може глобально вимагати надсилання через інструмент повідомлень; messages.groupChat.visibleReplies перевизначає це для груп і каналів.
  • Режими видимих відповідей, перевизначення для окремих каналів і режим чату із собою див. у повному довіднику.
Використовуйте agents.defaults.skills як спільну основу, а потім перевизначайте її для окремих агентів за допомогою agents.list[].skills:
  • Не вказуйте agents.defaults.skills, щоб Skills за замовчуванням не мали обмежень.
  • Не вказуйте agents.list[].skills, щоб успадкувати стандартні значення.
  • Установіть agents.list[].skills: [], щоб не використовувати Skills.
  • Див. Skills, Конфігурація Skills і Довідник із конфігурації.
Визначте, наскільки активно Gateway перезапускатиме канали, що здаються неактивними:
  • Показані значення є стандартними. Установіть gateway.channelHealthCheckMinutes: 0, щоб глобально вимкнути перезапуски моніторингом стану.
  • channelStaleEventThresholdMinutes має бути більшим або дорівнювати інтервалу перевірки.
  • Використовуйте channels.<provider>.healthMonitor.enabled або channels.<provider>.accounts.<id>.healthMonitor.enabled, щоб вимкнути автоматичні перезапуски для одного каналу чи облікового запису, не вимикаючи глобальний моніторинг.
  • Відомості про діагностику роботи див. у розділі Перевірки стану, а опис усіх полів — у повному довіднику.
Надайте локальним клієнтам більше часу для завершення рукостискання WebSocket перед автентифікацією на навантажених або малопотужних хостах:
  • За замовчуванням — 15000 мілісекунд.
  • OPENCLAW_HANDSHAKE_TIMEOUT_MS усе ще має пріоритет для одноразових перевизначень служби або оболонки.
  • Спочатку бажано усунути зависання під час запуску або в циклі подій; цей параметр призначений для справних хостів, які повільно прогріваються.
Сеанси керують безперервністю та ізоляцією розмов:
  • dmScope: main (спільний) | per-peer | per-channel-peer | per-account-channel-peer
  • threadBindings: глобальні типові параметри маршрутизації сеансів, прив’язаних до гілок. /focus, /unfocus, /agents, /session idle і /session max-age відповідно прив’язують, відв’язують, показують список і налаштовують це для кожного сеансу (Discord прив’язує гілки, Telegram — теми/розмови).
  • Відомості про області дії, зв’язки ідентичностей і політику надсилання див. у розділі Керування сеансами.
  • Опис усіх полів див. у повному довіднику.
Запускайте сеанси агентів в ізольованих середовищах виконання пісочниці:
Спочатку зберіть образ: із робочої копії вихідного коду виконайте scripts/sandbox-setup.sh, а для встановлення з npm див. вбудовану команду docker build у розділі Пісочниця § Образи та налаштування.Повний посібник див. у розділі Пісочниця, а всі параметри — у повному довіднику.
Для push-сповіщень у загальнодоступних збірках з App Store використовується розміщений ретранслятор OpenClaw: https://ios-push-relay.openclaw.ai.Власні розгортання ретранслятора потребують навмисно відокремленого процесу збирання та розгортання iOS, у якому URL-адреса ретранслятора збігається з URL-адресою ретранслятора Gateway. Якщо використовується власна збірка з ретранслятором, задайте це в конфігурації Gateway:
Еквівалент у CLI:
Результат:
  • Дає Gateway змогу надсилати push.test, сигнали пробудження та пробудження для повторного підключення через зовнішній ретранслятор.
  • Використовує дозвіл на надсилання, обмежений реєстрацією, який передає спарений застосунок iOS. Gateway не потребує токена ретранслятора для всього розгортання.
  • Прив’язує кожну реєстрацію через ретранслятор до ідентичності Gateway, з якою спарено застосунок iOS, щоб інший Gateway не міг повторно використати збережену реєстрацію.
  • Зберігає пряме використання APNs для локальних або ручних збірок iOS. Надсилання через ретранслятор застосовується лише до офіційно розповсюджуваних збірок, зареєстрованих через ретранслятор.
  • Має збігатися з базовою URL-адресою ретранслятора, вбудованою у збірку iOS, щоб трафік реєстрації та надсилання надходив до одного розгортання ретранслятора.
Наскрізний процес:
  1. Установіть офіційний застосунок iOS.
  2. Необов’язково: налаштуйте gateway.push.apns.relay.baseUrl у Gateway лише в разі використання навмисно відокремленої власної збірки з ретранслятором.
  3. Спарте застосунок iOS із Gateway і дозвольте підключитися сеансам Node та оператора.
  4. Застосунок iOS отримує ідентичність Gateway, реєструється в ретрансляторі за допомогою App Attest і квитанції застосунку, а потім публікує корисне навантаження push.apns.register через ретранслятор у спареному Gateway.
  5. Gateway зберігає дескриптор ретранслятора й дозвіл на надсилання, а потім використовує їх для push.test, сигналів пробудження та пробуджень для повторного підключення.
Примітки щодо експлуатації:
  • Якщо застосунок iOS перемкнено на інший Gateway, повторно підключіть застосунок, щоб він міг опублікувати нову реєстрацію ретранслятора, прив’язану до цього Gateway.
  • Якщо випущено нову збірку iOS, яка використовує інше розгортання ретранслятора, застосунок оновить кешовану реєстрацію ретранслятора замість повторного використання старого джерела ретранслятора.
Примітка щодо сумісності:
  • OPENCLAW_APNS_RELAY_BASE_URL і OPENCLAW_APNS_RELAY_TIMEOUT_MS усе ще працюють як тимчасові перевизначення через змінні середовища.
  • Власні URL-адреси ретранслятора Gateway мають збігатися з базовою URL-адресою ретранслятора, вбудованою у збірку iOS; загальнодоступний канал випуску App Store відхиляє перевизначення URL-адреси ретранслятора iOS.
  • OPENCLAW_APNS_RELAY_ALLOW_HTTP=true залишається аварійним механізмом лише для розробки через зворотний інтерфейс; не зберігайте URL-адреси HTTP-ретранслятора в конфігурації.
Наскрізний процес див. у розділі Застосунок iOS, а модель безпеки ретранслятора — у розділі Процес автентифікації та встановлення довіри.
  • every: рядок тривалості (30m, 2h). Щоб вимкнути, задайте 0m. За замовчуванням: 30m.
  • target: last | none | <channel-id> (наприклад, discord, matrix, telegram або whatsapp)
  • directPolicy: allow (за замовчуванням) або block для цілей Heartbeat у стилі особистих повідомлень
  • Повний посібник див. у розділі Heartbeat.
  • sessionRetention: видаляє завершені ізольовані сеанси запуску з рядків сеансів SQLite (за замовчуванням 24h; щоб вимкнути, задайте false).
  • У журналі запусків автоматично зберігаються 2000 найновіших кінцевих рядків для кожного завдання; для втрачених рядків зберігається 24-годинне вікно очищення.
  • Огляд функції та приклади CLI див. у розділі Завдання Cron.
Увімкніть кінцеві точки HTTP Webhook у Gateway:
Примітка щодо безпеки:
  • Вважайте весь вміст корисного навантаження обробників/Webhook недовіреними вхідними даними.
  • Використовуйте окремий hooks.token; не використовуйте повторно активні секрети автентифікації Gateway (gateway.auth.token / OPENCLAW_GATEWAY_TOKEN або gateway.auth.password / OPENCLAW_GATEWAY_PASSWORD).
  • Автентифікація обробників виконується лише через заголовки (Authorization: Bearer ... або x-openclaw-token); токени в рядку запиту відхиляються.
  • hooks.path не може бути /; розміщуйте вхідний трафік Webhook в окремому підшляху, наприклад /hooks.
  • Не вмикайте прапорці обходу перевірки небезпечного вмісту (hooks.gmail.allowUnsafeExternalContent, hooks.mappings[].allowUnsafeExternalContent), крім випадків суворо обмеженого налагодження.
  • Якщо ввімкнено hooks.allowRequestSessionKey, також задайте hooks.allowedSessionKeyPrefixes, щоб обмежити ключі сеансів, які може вибирати викликач.
  • Для агентів, керованих обробниками, віддавайте перевагу потужним сучасним рівням моделей і суворій політиці інструментів (наприклад, лише обмін повідомленнями та, де можливо, пісочниця).
Усі параметри зіставлення та інтеграцію з Gmail див. у повному довіднику.
Запускайте кілька ізольованих агентів з окремими робочими просторами та сеансами:
Правила прив’язування та профілі доступу для кожного агента див. у розділах Кілька агентів і повний довідник.
Використовуйте $include для впорядкування великих конфігурацій:
  • Один файл: замінює об’єкт, що його містить
  • Масив файлів: глибоко об’єднується за порядком (пізніші мають пріоритет), до 10 рівнів вкладеності
  • Сусідні ключі: об’єднуються після включень (перевизначають включені значення)
  • Відносні шляхи: визначаються відносно файлу, що виконує включення
  • Формат шляху: шляхи включення не повинні містити нульових байтів і мають бути строго коротшими за 4096 символів до та після визначення
  • Записи, керовані OpenClaw: коли запис змінює лише один розділ верхнього рівня, підтримуваний включенням одного файлу, наприклад plugins: { $include: "./plugins.json5" }, OpenClaw оновлює цей включений файл і залишає openclaw.json без змін
  • Непідтримуваний наскрізний запис: кореневі включення, масиви включень і включення із сусідніми перевизначеннями завершуються відмовою для записів, керованих OpenClaw, замість зведення конфігурації в один файл
  • Обмеження: шляхи $include мають визначатися в межах каталогу, що містить openclaw.json. Щоб спільно використовувати дерево на різних машинах або між користувачами, задайте OPENCLAW_INCLUDE_ROOTS як список шляхів (: у POSIX, ; у Windows) до додаткових каталогів, на які можуть посилатися включення. Символічні посилання визначаються та перевіряються повторно, тому шлях, який лексично міститься в каталозі конфігурації, але фактична ціль якого виходить за межі всіх дозволених коренів, усе одно відхиляється.
  • Обробка помилок: чіткі повідомлення про відсутні файли, помилки синтаксичного аналізу, циклічні включення, неправильний формат шляху та надмірну довжину

Гаряче перезавантаження конфігурації

Gateway стежить за ~/.openclaw/openclaw.json і автоматично застосовує зміни — для більшості параметрів ручний перезапуск не потрібен. Прямі зміни файлу вважаються недовіреними, доки не пройдуть перевірку. Спостерігач чекає, доки завершаться операції запису тимчасових файлів і перейменування в редакторі, читає остаточний файл та відхиляє неправильні зовнішні зміни, не перезаписуючи openclaw.json. Для записів конфігурації, керованих OpenClaw, перед записом використовується та сама перевірка схеми (правила перезапису й відновлення, що застосовуються до кожного запису, див. у розділі Сувора перевірка). Якщо з’являється config reload skipped (invalid config) або під час запуску повідомляється Invalid config, перевірте конфігурацію, виконайте openclaw config validate, а потім openclaw doctor --fix для виправлення. Контрольний список див. у розділі Усунення несправностей Gateway.

Режими перезавантаження

Що застосовується без перезапуску, а що потребує перезапуску

Більшість полів застосовуються без перезапуску й простою; деякі розділи, що застосовуються без перезапуску, перезапускають лише відповідну підсистему (канал, cron, heartbeat, монітор стану), а не весь Gateway. У режимі hybrid зміни, що потребують перезапуску Gateway, обробляються автоматично.
gateway.reload і gateway.remote є винятками в межах gateway.* — їх зміна не спричиняє перезапуск. Окремі плагіни також можуть перевизначати цю таблицю: завантажений плагін може оголосити власні префікси конфігурації, що спричиняють перезапуск (наприклад, вбудований плагін Canvas перезапускає Gateway для plugins.enabled, plugins.allow і plugins.deny, а не лише для власного plugins.entries.canvas), тому фактична поведінка залежить від того, які плагіни активні.

Планування перезавантаження

Коли ви редагуєте вихідний файл, на який посилається $include, OpenClaw планує перезавантаження на основі структури вихідних файлів, а не сплощеного подання в пам’яті. Це забезпечує передбачуваність рішень щодо гарячого перезавантаження (застосування без перезапуску чи перезапуск), навіть коли один розділ верхнього рівня міститься в окремому включеному файлі, як-от plugins: { $include: "./plugins.json5" }. Планування перезавантаження завершується безпечною відмовою, якщо структура вихідних файлів неоднозначна.

RPC конфігурації (програмні оновлення)

Для інструментів, які записують конфігурацію через API Gateway, рекомендовано такий процес:
  • config.schema.lookup для перевірки одного піддерева (неглибокий вузол схеми та зведення дочірніх елементів)
  • config.get для отримання поточного знімка разом із hash
  • config.patch для часткових оновлень (патч злиття JSON: об’єкти зливаються, null видаляє, масиви замінюються після явного підтвердження за допомогою replacePaths, якщо записи буде видалено)
  • config.apply лише коли потрібно замінити всю конфігурацію
  • update.run для явного самооновлення з перезапуском; додайте continuationMessage, якщо сеанс після перезапуску має виконати один додатковий хід
  • update.status для перевірки останнього маркера перезапуску після оновлення та версії, що працює після перезапуску
Агенти мають передусім звертатися до config.schema.lookup для отримання точної документації й обмежень на рівні полів. Використовуйте довідник із конфігурації, коли потрібна ширша карта конфігурації, значення за замовчуванням або посилання на спеціалізовані довідники підсистем.
Записи площини керування (config.apply, config.patch, update.run) обмежено до 3 запитів за 60 секунд на deviceId+clientIp. Запити на перезапуск об’єднуються, після чого між циклами перезапуску діє 30-секундний період очікування. update.status доступний лише для читання, але потребує прав адміністратора, оскільки маркер перезапуску може містити зведення кроків оновлення та кінцеві фрагменти виводу команд.
Приклад часткового патча:
І config.apply, і config.patch приймають raw, baseHash, sessionKey, note та restartDelayMs. baseHash є обов’язковим для обох методів, якщо файл конфігурації вже існує (під час першого запису без наявної конфігурації перевірка пропускається). config.patch також приймає replacePaths — масив шляхів конфігурації, для яких заміна масиву є навмисною. Якщо патч замінює або видаляє наявний масив, залишаючи менше записів, Gateway відхиляє запис, якщо точного шляху немає в replacePaths; вкладені масиви всередині елементів масиву використовують [], наприклад agents.list[].skills. Це запобігає непомітному перезаписуванню масивів маршрутизації або списків дозволів усіченими знімками config.get. Використовуйте config.apply, коли потрібно замінити всю конфігурацію.

Змінні середовища

OpenClaw зчитує змінні середовища з батьківського процесу, а також із:
  • .env у поточному робочому каталозі (якщо наявний)
  • ~/.openclaw/.env (глобальний резервний варіант)
Жоден із цих файлів не перевизначає наявні змінні середовища. Також можна задавати вбудовані змінні середовища в конфігурації:
Якщо цю функцію ввімкнено й очікувані ключі не задано, OpenClaw запускає вашу оболонку входу та імпортує лише відсутні ключі:
Еквівалентна змінна середовища: OPENCLAW_LOAD_SHELL_ENV=1. Значення timeoutMs за замовчуванням: 15000.
Посилайтеся на змінні середовища в будь-якому рядковому значенні конфігурації за допомогою ${VAR_NAME}:
Правила:
  • Зіставляються лише назви у верхньому регістрі: [A-Z_][A-Z0-9_]*
  • Відсутні або порожні змінні спричиняють помилку під час завантаження
  • Для буквального виводу екрануйте за допомогою $${VAR}
  • Працює у файлах $include
  • Вбудоване підставлення: "${BASE}/v1""https://api.example.com/v1"
Для полів, що підтримують об’єкти SecretRef, можна використовувати:
Докладні відомості про SecretRef (зокрема secrets.providers для env/file/exec) наведено в розділі Керування секретами. Підтримувані шляхи облікових даних перелічено в розділі Поверхня облікових даних SecretRef.
Повний порядок пріоритетів і джерела див. у розділі Середовище.

Повний довідник

Повний опис усіх полів див. у довіднику з конфігурації.
Пов’язані матеріали: Приклади конфігурації · Довідник із конфігурації · Doctor

Пов’язані матеріали