Skip to main content
OpenClaw odczytuje opcjonalną konfigurację z ~/.openclaw/openclaw.json. Jeśli plik nie istnieje, OpenClaw używa bezpiecznych wartości domyślnych. Aktywna ścieżka konfiguracji musi wskazywać zwykły plik. Zapisy wykonywane przez OpenClaw zastępują go atomowo (przez zmianę nazwy na ścieżkę docelową), więc w przypadku dowiązania symbolicznego openclaw.json zastąpiony zostanie jego cel, zamiast zapisania danych za pośrednictwem dowiązania — należy unikać układów konfiguracji korzystających z dowiązań symbolicznych. Jeśli konfiguracja znajduje się poza domyślnym katalogiem stanu, należy ustawić OPENCLAW_CONFIG_PATH bezpośrednio na rzeczywisty plik. Typowe powody dodania konfiguracji:
  • Połączenie kanałów i kontrolowanie, kto może wysyłać wiadomości do bota
  • Ustawienie modeli, narzędzi, piaskownicy lub automatyzacji (cron, hooki)
  • Dostrojenie sesji, multimediów, sieci lub interfejsu użytkownika
Opis wszystkich dostępnych pól znajduje się w pełnej dokumentacji referencyjnej. Agenci i automatyzacje powinni przed edycją konfiguracji użyć config.schema.lookup, aby uzyskać dokładną dokumentację poszczególnych pól. Ta strona zawiera wskazówki zorientowane na zadania, natomiast dokumentacja referencyjna konfiguracji przedstawia szerszą mapę pól i wartości domyślne.
Pierwszy kontakt z konfiguracją? Interaktywną konfigurację można rozpocząć za pomocą openclaw onboard albo skorzystać z przewodnika Przykłady konfiguracji, który zawiera kompletne konfiguracje gotowe do skopiowania i wklejenia.

Minimalna konfiguracja

Edytowanie konfiguracji

Ścisła walidacja

OpenClaw akceptuje wyłącznie konfiguracje w pełni zgodne ze schematem. Nieznane klucze, nieprawidłowe typy lub niepoprawne wartości powodują, że Gateway odmawia uruchomienia. Jedynym wyjątkiem na poziomie głównym jest $schema (ciąg znaków), dzięki któremu edytory mogą dołączać metadane schematu JSON.
openclaw config schema wyświetla kanoniczny schemat JSON używany przez interfejs sterowania i mechanizm walidacji. config.schema.lookup pobiera pojedynczy węzeł ograniczony do wskazanej ścieżki wraz z podsumowaniami elementów podrzędnych dla narzędzi umożliwiających szczegółową analizę. Metadane dokumentacji pól title/description są przenoszone przez zagnieżdżone obiekty, symbole wieloznaczne (*), elementy tablic ([]) oraz gałęzie anyOf/oneOf/allOf. Schematy pluginów i kanałów środowiska uruchomieniowego są scalane po załadowaniu rejestru manifestów. Gdy walidacja zakończy się niepowodzeniem:
  • Gateway nie uruchamia się
  • Działają tylko polecenia diagnostyczne (openclaw doctor, openclaw logs, openclaw health, openclaw status)
  • Należy uruchomić openclaw doctor, aby wyświetlić dokładne problemy
  • Należy uruchomić openclaw doctor --fix (--repair jest tą samą flagą; --yes pomija monity), aby zastosować naprawy
Po każdym pomyślnym uruchomieniu Gateway zachowuje zaufaną kopię ostatniej znanej poprawnej konfiguracji, ale uruchamianie i przeładowywanie na gorąco nie przywracają jej automatycznie — robi to wyłącznie openclaw doctor --fix. Jeśli openclaw.json nie przejdzie walidacji (w tym walidacji lokalnej pluginu), uruchomienie Gateway kończy się niepowodzeniem albo przeładowanie zostaje pominięte, a bieżące środowisko uruchomieniowe nadal korzysta z ostatniej zaakceptowanej konfiguracji. Odrzucony zapis jest również zapisywany jako <path>.rejected.<timestamp> do celów inspekcji. Gateway blokuje zapisy wyglądające na przypadkowe nadpisanie — usunięcie gateway.mode, utratę bloku meta lub zmniejszenie pliku o ponad połowę — chyba że zapis jawnie zezwala na destrukcyjne zmiany. Kandydat nie jest promowany do ostatniej znanej poprawnej konfiguracji, jeśli zawiera symbol zastępczy zredagowanego sekretu, taki jak *** lub [redacted].

Typowe zadania

Każdy kanał ma własną sekcję konfiguracji w channels.<provider>. Instrukcje konfiguracji znajdują się na stronie poświęconej danemu kanałowi:Wszystkie kanały korzystają z tego samego wzorca zasad wiadomości prywatnych:
Należy ustawić model podstawowy i opcjonalne modele zastępcze:
  • agents.defaults.models definiuje katalog modeli i pełni funkcję listy dozwolonych dla /model; wpisy provider/* ograniczają /model, /models i selektory modeli do wybranych dostawców, nadal korzystając z dynamicznego wykrywania modeli.
  • Aby dodać wpisy do listy dozwolonych bez usuwania istniejących modeli, należy użyć openclaw config set agents.defaults.models '<json>' --strict-json --merge. Zwykłe zastąpienia, które spowodowałyby usunięcie wpisów, są odrzucane, chyba że przekazano --replace.
  • Odwołania do modeli używają formatu provider/model (np. anthropic/claude-opus-4-6).
  • agents.defaults.imageMaxDimensionPx steruje zmniejszaniem rozdzielczości obrazów w transkrypcjach i narzędziach (domyślnie 1200); niższe wartości zazwyczaj ograniczają użycie tokenów wizyjnych podczas przebiegów z dużą liczbą zrzutów ekranu.
  • Informacje o przełączaniu modeli na czacie znajdują się w CLI modeli, a informacje o rotacji uwierzytelniania i działaniu modeli zastępczych — w Przełączaniu awaryjnym modeli.
  • Informacje o niestandardowych lub samodzielnie hostowanych dostawcach znajdują się w sekcji Niestandardowi dostawcy dokumentacji referencyjnej.
Dostęp do wiadomości prywatnych jest kontrolowany osobno dla każdego kanału za pomocą dmPolicy (domyślnie "pairing"):
  • "pairing": nieznani nadawcy otrzymują jednorazowy kod parowania wymagający zatwierdzenia
  • "allowlist": dostęp mają tylko nadawcy z allowFrom (lub ze sparowanego magazynu dozwolonych)
  • "open": zezwala na wszystkie przychodzące wiadomości prywatne (wymaga allowFrom: ["*"])
  • "disabled": ignoruje wszystkie wiadomości prywatne
W przypadku grup należy użyć groupPolicy ("allowlist" | "open" | "disabled") wraz z groupAllowFrom lub listami dozwolonych właściwymi dla kanału.Szczegóły dotyczące poszczególnych kanałów znajdują się w pełnej dokumentacji referencyjnej.
Wiadomości grupowe domyślnie wymagają wzmianki. Wzorce wyzwalające konfiguruje się osobno dla każdego agenta. Zwykłe odpowiedzi w grupie lub kanale są publikowane automatycznie; w pokojach współdzielonych, w których agent powinien decydować, kiedy się odezwać, należy włączyć ścieżkę narzędzia wiadomości:
  • Wzmianki w metadanych: natywne wzmianki @ (dotknięcie wzmianki w WhatsApp, @bot w Telegramie itp.)
  • Wzorce tekstowe: bezpieczne wzorce wyrażeń regularnych w mentionPatterns
  • Widoczne odpowiedzi: messages.visibleReplies może globalnie wymagać wysyłania za pomocą narzędzia wiadomości; messages.groupChat.visibleReplies zastępuje to ustawienie dla grup i kanałów.
  • Tryby widocznych odpowiedzi, ustawienia zastępujące dla poszczególnych kanałów i tryb czatu z samym sobą opisano w pełnej dokumentacji referencyjnej.
Należy użyć agents.defaults.skills jako wspólnej konfiguracji bazowej, a następnie zastąpić ją dla określonych agentów za pomocą agents.list[].skills:
Można określić, jak agresywnie Gateway ma ponownie uruchamiać kanały, które wydają się nieaktywne:
  • Przedstawione wartości są domyślne. Aby globalnie wyłączyć ponowne uruchamianie przez monitor stanu, należy ustawić gateway.channelHealthCheckMinutes: 0.
  • channelStaleEventThresholdMinutes powinno być większe lub równe interwałowi sprawdzania.
  • Aby wyłączyć automatyczne ponowne uruchamianie pojedynczego kanału lub konta bez wyłączania globalnego monitora, należy użyć channels.<provider>.healthMonitor.enabled lub channels.<provider>.accounts.<id>.healthMonitor.enabled.
  • Informacje o debugowaniu operacyjnym znajdują się w Kontrolach stanu, a opis wszystkich pól — w pełnej dokumentacji referencyjnej.
Lokalnym klientom można zapewnić więcej czasu na ukończenie uzgadniania WebSocket poprzedzającego uwierzytelnianie na obciążonych hostach lub hostach o małej mocy:
  • Wartość domyślna to 15000 milisekund.
  • OPENCLAW_HANDSHAKE_TIMEOUT_MS nadal ma pierwszeństwo w przypadku jednorazowych nadpisań usługi lub powłoki.
  • Najpierw należy usunąć zastoje podczas uruchamiania lub w pętli zdarzeń; to ustawienie jest przeznaczone dla hostów, które działają prawidłowo, ale wolno podczas rozgrzewania.
Sesje kontrolują ciągłość i izolację konwersacji:
  • dmScope: main (współdzielone) | per-peer | per-channel-peer | per-account-channel-peer
  • threadBindings: globalne wartości domyślne routingu sesji powiązanych z wątkami. /focus, /unfocus, /agents, /session idle i /session max-age odpowiednio wiążą, usuwają powiązanie, wyświetlają listę i dostosowują to ustawienie dla poszczególnych sesji (Discord wiąże wątki, Telegram wiąże tematy/konwersacje).
  • Informacje o zakresach, powiązaniach tożsamości i zasadach wysyłania zawiera sekcja Zarządzanie sesjami.
  • Wszystkie pola opisano w pełnej dokumentacji.
Sesje agentów można uruchamiać w izolowanych środowiskach piaskownicy:
Najpierw należy zbudować obraz — w repozytorium źródłowym należy uruchomić scripts/sandbox-setup.sh, a w przypadku instalacji z npm użyć wbudowanego polecenia docker build opisanego w sekcji Piaskownica § Obrazy i konfiguracja.Pełny przewodnik zawiera sekcja Piaskownica, a wszystkie opcje opisano w pełnej dokumentacji.
Przekazywane powiadomienia push w publicznych kompilacjach z App Store korzystają z hostowanej usługi przekazywania OpenClaw: https://ios-push-relay.openclaw.ai.Niestandardowe wdrożenia usługi przekazywania wymagają celowo oddzielnej ścieżki kompilacji i wdrażania iOS, której adres URL usługi przekazywania jest zgodny z adresem URL usługi przekazywania Gateway. W przypadku korzystania z niestandardowej kompilacji usługi przekazywania należy ustawić w konfiguracji Gateway:
Odpowiednik w CLI:
Działanie:
  • Umożliwia Gateway wysyłanie push.test, sygnałów wybudzania i wybudzeń ponownego połączenia przez zewnętrzną usługę przekazywania.
  • Używa uprawnienia do wysyłania ograniczonego do rejestracji, przekazanego przez sparowaną aplikację iOS. Gateway nie wymaga tokenu usługi przekazywania obejmującego całe wdrożenie.
  • Wiąże każdą rejestrację korzystającą z usługi przekazywania z tożsamością Gateway, z którą sparowano aplikację iOS, dzięki czemu inny Gateway nie może ponownie użyć zapisanej rejestracji.
  • Pozostawia lokalne/ręczne kompilacje iOS przy bezpośrednim korzystaniu z APNs. Wysyłanie przez usługę przekazywania dotyczy tylko oficjalnie dystrybuowanych kompilacji zarejestrowanych za jej pośrednictwem.
  • Musi odpowiadać bazowemu adresowi URL usługi przekazywania wbudowanemu w kompilację iOS, aby ruch rejestracyjny i wysyłania trafiał do tego samego wdrożenia usługi przekazywania.
Przepływ kompleksowy:
  1. Zainstalować oficjalną aplikację iOS.
  2. Opcjonalnie: skonfigurować gateway.push.apns.relay.baseUrl w Gateway wyłącznie w przypadku korzystania z celowo oddzielnej, niestandardowej kompilacji usługi przekazywania.
  3. Sparować aplikację iOS z Gateway i umożliwić połączenie sesji Node oraz operatora.
  4. Aplikacja iOS pobiera tożsamość Gateway, rejestruje się w usłudze przekazywania przy użyciu App Attest oraz potwierdzenia zakupu aplikacji, a następnie publikuje do sparowanego Gateway ładunek push.apns.register obsługiwany przez usługę przekazywania.
  5. Gateway zapisuje uchwyt usługi przekazywania i uprawnienie do wysyłania, a następnie używa ich dla push.test, sygnałów wybudzania i wybudzeń ponownego połączenia.
Uwagi operacyjne:
  • Po przełączeniu aplikacji iOS na inny Gateway należy ponownie połączyć aplikację, aby mogła opublikować nową rejestrację usługi przekazywania powiązaną z tym Gateway.
  • W przypadku wydania nowej kompilacji iOS wskazującej inne wdrożenie usługi przekazywania aplikacja odświeża rejestrację usługi przekazywania w pamięci podręcznej zamiast ponownie używać starego źródła usługi.
Uwaga dotycząca zgodności:
  • OPENCLAW_APNS_RELAY_BASE_URL i OPENCLAW_APNS_RELAY_TIMEOUT_MS nadal działają jako tymczasowe nadpisania za pomocą zmiennych środowiskowych.
  • Niestandardowe adresy URL usługi przekazywania Gateway muszą odpowiadać bazowemu adresowi URL wbudowanemu w kompilację iOS; publiczny kanał wydań App Store odrzuca nadpisania niestandardowego adresu URL usługi przekazywania iOS.
  • OPENCLAW_APNS_RELAY_ALLOW_HTTP=true pozostaje mechanizmem awaryjnym przeznaczonym wyłącznie do programowania w pętli zwrotnej; nie należy trwale zapisywać adresów URL usługi przekazywania HTTP w konfiguracji.
Kompleksowy przepływ opisano w sekcji Aplikacja iOS, a model zabezpieczeń usługi przekazywania w sekcji Przepływ uwierzytelniania i zaufania.
  • every: ciąg określający czas trwania (30m, 2h). Aby wyłączyć, należy ustawić 0m. Wartość domyślna: 30m.
  • target: last | none | <channel-id> (na przykład discord, matrix, telegram lub whatsapp)
  • directPolicy: allow (domyślnie) lub block dla celów Heartbeat typu DM
  • Pełny przewodnik zawiera sekcja Heartbeat.
  • sessionRetention: usuwa zakończone sesje izolowanych przebiegów z wierszy sesji SQLite (domyślnie 24h; aby wyłączyć, należy ustawić false).
  • Historia przebiegów automatycznie zachowuje najnowsze 2000 końcowych wierszy na zadanie; utracone wiersze zachowują 24-godzinne okno usuwania.
  • Omówienie funkcji i przykłady użycia CLI zawiera sekcja Zadania Cron.
Włączanie punktów końcowych HTTP Webhook na Gateway:
Uwaga dotycząca bezpieczeństwa:
  • Całą zawartość ładunków hooków/Webhooków należy traktować jako niezaufane dane wejściowe.
  • Należy użyć dedykowanego hooks.token; nie należy ponownie używać aktywnych sekretów uwierzytelniających Gateway (gateway.auth.token / OPENCLAW_GATEWAY_TOKEN ani gateway.auth.password / OPENCLAW_GATEWAY_PASSWORD).
  • Uwierzytelnianie hooków odbywa się wyłącznie za pomocą nagłówka (Authorization: Bearer ... lub x-openclaw-token); tokeny w ciągu zapytania są odrzucane.
  • hooks.path nie może mieć wartości /; ruch przychodzący Webhooków należy utrzymywać w dedykowanej podścieżce, takiej jak /hooks.
  • Flagi pomijania zabezpieczeń dla niebezpiecznej zawartości (hooks.gmail.allowUnsafeExternalContent, hooks.mappings[].allowUnsafeExternalContent) powinny pozostać wyłączone, z wyjątkiem ściśle ograniczonego debugowania.
  • W przypadku włączenia hooks.allowRequestSessionKey należy także ustawić hooks.allowedSessionKeyPrefixes, aby ograniczyć klucze sesji wybierane przez wywołującego.
  • W przypadku agentów uruchamianych przez hooki zaleca się zaawansowane, nowoczesne poziomy modeli i rygorystyczne zasady dotyczące narzędzi (na przykład tylko obsługa wiadomości oraz piaskownica, gdy jest to możliwe).
Wszystkie opcje mapowania i integrację z Gmailem opisano w pełnej dokumentacji.
Uruchamianie wielu izolowanych agentów z oddzielnymi obszarami roboczymi i sesjami:
Reguły powiązań i profile dostępu poszczególnych agentów opisano w sekcjach Wielu agentów i pełna dokumentacja.
Duże konfiguracje można porządkować za pomocą $include:
  • Pojedynczy plik: zastępuje obiekt zawierający
  • Tablica plików: scalana głęboko w kolejności (późniejsze wartości mają pierwszeństwo), maksymalnie do 10 poziomów zagnieżdżenia
  • Klucze równorzędne: scalane po dołączeniu plików (nadpisują dołączone wartości)
  • Ścieżki względne: rozwiązywane względem pliku dołączającego
  • Format ścieżki: ścieżki dołączanych plików nie mogą zawierać bajtów null i muszą mieć ściśle mniej niż 4096 znaków przed i po rozwiązaniu
  • Zapisy wykonywane przez OpenClaw: gdy zapis zmienia tylko jedną sekcję najwyższego poziomu opartą na dołączeniu pojedynczego pliku, takim jak plugins: { $include: "./plugins.json5" }, OpenClaw aktualizuje ten dołączony plik i pozostawia openclaw.json bez zmian
  • Nieobsługiwane przekazywanie zapisu: dołączenia główne, tablice dołączeń oraz dołączenia z równorzędnymi nadpisaniami są bezpiecznie odrzucane podczas zapisów wykonywanych przez OpenClaw zamiast spłaszczania konfiguracji
  • Ograniczenie: ścieżki $include muszą rozwiązywać się w katalogu zawierającym openclaw.json. Aby współdzielić drzewo między komputerami lub użytkownikami, należy ustawić OPENCLAW_INCLUDE_ROOTS na listę ścieżek (: w systemach POSIX, ; w systemie Windows) do dodatkowych katalogów, do których mogą odwoływać się dołączenia. Dowiązania symboliczne są rozwiązywane i ponownie sprawdzane, dlatego ścieżka, która leksykalnie znajduje się w katalogu konfiguracji, ale której rzeczywisty cel wychodzi poza każdy dozwolony katalog główny, nadal jest odrzucana.
  • Obsługa błędów: czytelne błędy dotyczące brakujących plików, błędów analizy składni, cyklicznych dołączeń, nieprawidłowego formatu ścieżki i nadmiernej długości

Przeładowywanie konfiguracji na gorąco

Gateway obserwuje ~/.openclaw/openclaw.json i automatycznie stosuje zmiany — w przypadku większości ustawień ręczne ponowne uruchomienie nie jest potrzebne. Bezpośrednie edycje pliku są traktowane jako niezaufane, dopóki nie przejdą walidacji. Mechanizm obserwujący czeka na zakończenie tymczasowych zapisów i zmian nazw wykonywanych przez edytor, odczytuje ostateczny plik i odrzuca nieprawidłowe zmiany zewnętrzne bez ponownego zapisywania openclaw.json. Zapisy konfiguracji wykonywane przez OpenClaw przechodzą tę samą walidację schematu przed zapisem (reguły nadpisywania i wycofywania zmian dotyczące każdego zapisu opisano w sekcji Ścisła walidacja). Jeśli pojawi się config reload skipped (invalid config) lub podczas uruchamiania zostanie zgłoszone Invalid config, należy sprawdzić konfigurację, uruchomić openclaw config validate, a następnie uruchomić openclaw doctor --fix, aby ją naprawić. Lista kontrolna znajduje się w sekcji Rozwiązywanie problemów z Gateway.

Tryby przeładowywania

Które zmiany są stosowane bez restartu, a które go wymagają

Większość pól jest stosowana bez restartu i bez przestojów; niektóre sekcje stosowane bez restartu uruchamiają ponownie tylko dany podsystem (kanał, cron, heartbeat, monitor kondycji), a nie cały Gateway. W trybie hybrid zmiany wymagające ponownego uruchomienia Gateway są obsługiwane automatycznie.
gateway.reload i gateway.remote są wyjątkami w ramach gateway.* — ich zmiana nie wyzwala ponownego uruchomienia. Poszczególne pluginy mogą również zastępować tę tabelę: załadowany plugin może deklarować własne prefiksy konfiguracji wyzwalające ponowne uruchomienie (na przykład dołączony plugin Canvas uruchamia Gateway ponownie dla plugins.enabled, plugins.allow i plugins.deny, a nie tylko dla własnego plugins.entries.canvas), dlatego rzeczywiste zachowanie zależy od aktywnych pluginów.

Planowanie przeładowania

Podczas edycji pliku źródłowego, do którego odwołuje się $include, OpenClaw planuje przeładowanie na podstawie układu zapisanego w źródle, a nie spłaszczonego widoku w pamięci. Dzięki temu decyzje dotyczące przeładowania bez restartu (zastosowanie bez restartu lub ponowne uruchomienie) pozostają przewidywalne, nawet gdy pojedyncza sekcja najwyższego poziomu znajduje się we własnym dołączonym pliku, takim jak plugins: { $include: "./plugins.json5" }. Planowanie przeładowania kończy się bezpiecznym niepowodzeniem, jeśli układ źródłowy jest niejednoznaczny.

RPC konfiguracji (aktualizacje programowe)

W przypadku narzędzi zapisujących konfigurację za pośrednictwem API Gateway zalecany jest następujący przebieg:
  • config.schema.lookup, aby sprawdzić jedno poddrzewo (płytki węzeł schematu i podsumowania elementów podrzędnych)
  • config.get, aby pobrać bieżącą migawkę wraz z hash
  • config.patch do częściowych aktualizacji (poprawka scalająca JSON: obiekty są scalane, null usuwa, a tablice są zastępowane po jawnym potwierdzeniu za pomocą replacePaths, jeśli wpisy zostałyby usunięte)
  • config.apply tylko wtedy, gdy zamierzone jest zastąpienie całej konfiguracji
  • update.run do jawnej samodzielnej aktualizacji i ponownego uruchomienia; należy dołączyć continuationMessage, jeśli sesja po ponownym uruchomieniu ma wykonać jeden dodatkowy przebieg
  • update.status, aby sprawdzić najnowszy znacznik ponownego uruchomienia po aktualizacji i zweryfikować uruchomioną wersję po ponownym uruchomieniu
Agenty powinny w pierwszej kolejności korzystać z config.schema.lookup, aby uzyskać dokładną dokumentację i ograniczenia na poziomie pól. Należy użyć dokumentacji konfiguracji, gdy potrzebna jest szersza mapa konfiguracji, wartości domyślne lub odsyłacze do dedykowanej dokumentacji podsystemów.
Zapisy płaszczyzny sterowania (config.apply, config.patch, update.run) są ograniczone do 3 żądań na 60 sekund na deviceId+clientIp. Żądania ponownego uruchomienia są łączone, po czym obowiązuje 30-sekundowy okres oczekiwania między cyklami ponownego uruchomienia. update.status jest tylko do odczytu, ale wymaga uprawnień administratora, ponieważ znacznik ponownego uruchomienia może zawierać podsumowania kroków aktualizacji i końcowe fragmenty danych wyjściowych poleceń.
Przykładowa częściowa poprawka:
Zarówno config.apply, jak i config.patch akceptują raw, baseHash, sessionKey, note oraz restartDelayMs. baseHash jest wymagane dla obu metod, gdy plik konfiguracji już istnieje (pierwszy zapis bez istniejącej konfiguracji pomija tę kontrolę). config.patch akceptuje również replacePaths, czyli tablicę ścieżek konfiguracji, dla których zastąpienie tablicy jest zamierzone. Jeśli poprawka zastąpiłaby lub usunęła istniejącą tablicę, pozostawiając mniej wpisów, Gateway odrzuci zapis, chyba że dokładnie ta ścieżka znajduje się w replacePaths; zagnieżdżone tablice we wpisach tablic używają [], na przykład agents.list[].skills. Zapobiega to cichemu nadpisywaniu tablic routingu lub list dozwolonych przez obcięte migawki config.get. Należy użyć config.apply, gdy zamierzone jest zastąpienie całej konfiguracji.

Zmienne środowiskowe

OpenClaw odczytuje zmienne środowiskowe z procesu nadrzędnego oraz z:
  • .env w bieżącym katalogu roboczym (jeśli istnieje)
  • ~/.openclaw/.env (globalna wartość rezerwowa)
Żaden z tych plików nie zastępuje istniejących zmiennych środowiskowych. Zmienne środowiskowe można również ustawić bezpośrednio w konfiguracji:
Jeśli ta funkcja jest włączona, a oczekiwane klucze nie są ustawione, OpenClaw uruchamia powłokę logowania i importuje tylko brakujące klucze:
Odpowiednik w postaci zmiennej środowiskowej: OPENCLAW_LOAD_SHELL_ENV=1. Domyślne timeoutMs: 15000.
Do zmiennych środowiskowych można odwoływać się w dowolnej wartości ciągu konfiguracji za pomocą ${VAR_NAME}:
Reguły:
  • Dopasowywane są tylko nazwy zapisane wielkimi literami: [A-Z_][A-Z0-9_]*
  • Brakujące lub puste zmienne powodują błąd podczas ładowania
  • Sekwencja ucieczki $${VAR} pozwala uzyskać dosłowny tekst wyjściowy
  • Działa wewnątrz plików $include
  • Podstawianie w tekście: "${BASE}/v1""https://api.example.com/v1"
W przypadku pól obsługujących obiekty SecretRef można użyć:
Szczegóły SecretRef (w tym secrets.providers dla env/file/exec) znajdują się w sekcji Zarządzanie sekretami. Obsługiwane ścieżki danych uwierzytelniających wymieniono w sekcji Zakres danych uwierzytelniających SecretRef.
Pełną kolejność pierwszeństwa i źródła opisano w sekcji Środowisko.

Pełna dokumentacja

Pełną dokumentację wszystkich pól zawiera Dokumentacja konfiguracji.
Powiązane: Przykłady konfiguracji · Dokumentacja konfiguracji · Doctor

Powiązane