Przejdź do głównej treści
Zatwierdzenia exec są zabezpieczeniem aplikacji towarzyszącej / hosta węzła, które pozwala agentowi w piaskownicy uruchamiać polecenia na prawdziwym hoście (gateway lub node). To blokada bezpieczeństwa: polecenia są dozwolone tylko wtedy, gdy polityka + lista dozwolonych + (opcjonalne) zatwierdzenie użytkownika są zgodne. Zatwierdzenia exec nakładają się na politykę narzędzi i bramkowanie podwyższone (chyba że podwyższenie jest ustawione na full, co pomija zatwierdzenia). Omówienie trybów deny, allowlist, ask, auto, full, mapowania Codex Guardian oraz uprawnień uprzęży ACPX w ujęciu od trybu znajdziesz w Tryby uprawnień.
Efektywna polityka jest bardziej restrykcyjna z tools.exec.* i domyślnych zatwierdzeń; jeśli pole zatwierdzeń jest pominięte, używana jest wartość tools.exec. Exec hosta używa też lokalnego stanu zatwierdzeń na tej maszynie - lokalne dla hosta ask: "always" w pliku zatwierdzeń hosta wykonawczego nadal będzie pytać, nawet jeśli domyślne ustawienia sesji lub konfiguracji żądają ask: "on-miss".

​
Sprawdzanie efektywnej polityki

PolecenieCo pokazuje
openclaw approvals get / --gateway / --node <id|name|ip>Żądana polityka, źródła polityki hosta i efektywny wynik.
openclaw exec-policy showScalony widok maszyny lokalnej.
openclaw exec-policy set / presetSynchronizuje lokalnie żądaną politykę z lokalnym plikiem zatwierdzeń hosta w jednym kroku.
Gdy zakres lokalny żąda host=node, exec-policy show zgłasza ten zakres w czasie działania jako zarządzany przez węzeł, zamiast udawać, że lokalny plik zatwierdzeń jest źródłem prawdy. Jeśli interfejs aplikacji towarzyszącej jest niedostępny, każde żądanie, które normalnie wywołałoby monit, jest rozstrzygane przez awaryjny tryb ask (domyślnie: deny).
Natywni klienci zatwierdzania w czacie mogą inicjować udogodnienia specyficzne dla kanału w oczekującej wiadomości zatwierdzenia. Na przykład Matrix inicjuje skróty reakcji (✅ zezwól raz, ❌ odmów, ♾️ zawsze zezwalaj), nadal pozostawiając polecenia /approve ... w wiadomości jako rozwiązanie awaryjne.

​
Gdzie to ma zastosowanie

Zatwierdzenia exec są egzekwowane lokalnie na hoście wykonawczym:
  • Host Gateway → proces openclaw na maszynie Gateway.
  • Host węzła → uruchamiacz węzła (aplikacja towarzysząca macOS lub bezgłowy host węzła).

​
Model zaufania

  • Wywołujący uwierzytelnieni przez Gateway są zaufanymi operatorami tego Gateway.
  • Sparowane węzły rozszerzają tę możliwość zaufanego operatora na host węzła.
  • Zatwierdzenia exec zmniejszają ryzyko przypadkowego wykonania, ale nie są granicą uwierzytelniania per użytkownik ani polityką tylko do odczytu systemu plików.
  • Po zatwierdzeniu polecenie może modyfikować pliki zgodnie z wybranymi uprawnieniami hosta lub systemu plików piaskownicy.
  • Zatwierdzone uruchomienia na hoście węzła wiążą kanoniczny kontekst wykonania: kanoniczny cwd, dokładne argv, wiązanie env, gdy jest obecne, oraz przypiętą ścieżkę pliku wykonywalnego, gdy ma zastosowanie.
  • W przypadku skryptów powłoki oraz bezpośrednich wywołań plików interpretera/środowiska uruchomieniowego OpenClaw próbuje też powiązać jeden konkretny lokalny operand plikowy. Jeśli ten powiązany plik zmieni się po zatwierdzeniu, ale przed wykonaniem, uruchomienie zostanie odrzucone zamiast wykonywania treści, która uległa zmianie.
  • Wiązanie plików jest celowo najlepszym możliwym przybliżeniem, nie kompletnym modelem semantycznym każdej ścieżki ładowania interpretera/środowiska uruchomieniowego. Jeśli tryb zatwierdzania nie może zidentyfikować dokładnie jednego konkretnego lokalnego pliku do powiązania, odmawia wystawienia uruchomienia opartego na zatwierdzeniu, zamiast udawać pełne pokrycie.

​
Podział macOS

  • Usługa hosta węzła przekazuje system.run do aplikacji macOS przez lokalne IPC.
  • Aplikacja macOS egzekwuje zatwierdzenia i wykonuje polecenie w kontekście interfejsu użytkownika.

​
Ustawienia i przechowywanie

Zatwierdzenia znajdują się w lokalnym pliku JSON na hoście wykonawczym. Gdy OPENCLAW_STATE_DIR jest ustawione, plik podąża za tym katalogiem stanu; w przeciwnym razie używa domyślnego katalogu stanu OpenClaw: 
$OPENCLAW_STATE_DIR/exec-approvals.json
# otherwise
~/.openclaw/exec-approvals.json
Domyślne gniazdo zatwierdzeń używa tego samego katalogu głównego: $OPENCLAW_STATE_DIR/exec-approvals.sock albo ~/.openclaw/exec-approvals.sock, gdy zmienna nie jest ustawiona. Przykładowy schemat: 
{
  "version": 1,
  "socket": {
    "path": "~/.openclaw/exec-approvals.sock",
    "token": "base64url-token"
  },
  "defaults": {
    "security": "deny",
    "ask": "on-miss",
    "askFallback": "deny",
    "autoAllowSkills": false
  },
  "agents": {
    "main": {
      "security": "allowlist",
      "ask": "on-miss",
      "askFallback": "deny",
      "autoAllowSkills": true,
      "allowlist": [
        {
          "id": "B0C8C0B3-2C2D-4F8A-9A3C-5A4B3C2D1E0F",
          "pattern": "~/Projects/**/bin/rg",
          "source": "allow-always",
          "commandText": "rg -n TODO",
          "lastUsedAt": 1737150000000,
          "lastUsedCommand": "rg -n TODO",
          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"
        }
      ]
    }
  }
}

​
Pokrętła polityki

​
tools.exec.mode

tools.exec.mode to preferowana znormalizowana powierzchnia polityki dla exec hosta. Wartości to:
  • deny - blokuje exec hosta.
  • allowlist - uruchamia tylko polecenia z listy dozwolonych bez pytania.
  • ask - używa polityki listy dozwolonych i pyta przy chybieniach.
  • auto - używa polityki listy dozwolonych, uruchamia deterministyczne dopasowania bezpośrednio i wysyła chybienia zatwierdzeń przez natywnego automatycznego recenzenta OpenClaw przed powrotem do ścieżki zatwierdzenia przez człowieka.
  • full - uruchamia exec hosta bez monitów o zatwierdzenie.
Starsze tools.exec.security / tools.exec.ask pozostają obsługiwane i nadal wygrywają, gdy są ustawione w węższym zakresie sesji lub agenta.

​
exec.security

​
security
"deny" | "allowlist" | "full"
  • deny - blokuje wszystkie żądania exec hosta.
  • allowlist - zezwala tylko na polecenia z listy dozwolonych.
  • full - zezwala na wszystko (równoważne podwyższeniu).

​
exec.ask

​
ask
"off" | "on-miss" | "always"
Skonfigurowana polityka ask dla exec hosta. Kontroluje bazowe zachowanie monitu o zatwierdzenie z tools.exec.ask oraz domyślnych zatwierdzeń hosta. Parametr narzędzia ask dla pojedynczego wywołania (zobacz Narzędzie exec) może tylko zaostrzyć tę bazę, a wywołania modelu pochodzące z kanału ignorują go, gdy efektywne ask hosta to off.
  • off - nigdy nie pokazuj monitu.
  • on-miss - pokazuj monit tylko wtedy, gdy lista dozwolonych nie pasuje.
  • always - pokazuj monit przy każdym poleceniu. Trwałe zaufanie allow-always nie tłumi monitów, gdy efektywny tryb ask to always.

​
askFallback

​
askFallback
"deny" | "allowlist" | "full"
Rozstrzygnięcie, gdy monit jest wymagany, ale żaden interfejs użytkownika nie jest osiągalny. Jeśli to pole jest pominięte, OpenClaw domyślnie używa deny.
  • deny - blokuj.
  • allowlist - zezwól tylko, jeśli pasuje lista dozwolonych.
  • full - zezwól.

​
tools.exec.strictInlineEval

​
strictInlineEval
boolean
Gdy true, OpenClaw traktuje formularze inline code-eval jako wymagające wyłącznie zatwierdzenia, nawet jeśli sam plik binarny interpretera znajduje się na liście dozwolonych. Obrona warstwowa dla loaderów interpreterów, które nie mapują się czysto na jeden stabilny operand plikowy.
Przykłady, które wychwytuje tryb ścisły:
  • python -c
  • node -e, node --eval, node -p
  • ruby -e
  • perl -e, perl -E
  • php -r
  • lua -e
  • osascript -e
W trybie ścisłym te polecenia nadal wymagają wyraźnego zatwierdzenia, a allow-always nie utrwala dla nich automatycznie nowych wpisów listy dozwolonych.

​
tools.exec.commandHighlighting

​
commandHighlighting
boolean
domyślnie:"false"
Kontroluje tylko prezentację w monitach zatwierdzeń exec. Po włączeniu OpenClaw może dołączać zakresy poleceń wyprowadzone z parsera, aby monity zatwierdzania w sieci Web mogły podświetlać tokeny polecenia. Ustaw na true, aby włączyć podświetlanie tekstu polecenia.
To ustawienie nie zmienia security, ask, dopasowywania listy dozwolonych, zachowania ścisłego inline-eval, przekazywania zatwierdzeń ani wykonywania poleceń. Można je ustawić globalnie w tools.exec.commandHighlighting lub dla agenta w agents.list[].tools.exec.commandHighlighting.

​
Tryb YOLO (bez zatwierdzeń)

Jeśli chcesz, aby exec hosta działał bez monitów o zatwierdzenie, musisz otworzyć obie warstwy polityki - żądaną politykę exec w konfiguracji OpenClaw (tools.exec.*) oraz lokalną dla hosta politykę zatwierdzeń w pliku zatwierdzeń hosta wykonawczego. OpenClaw domyślnie ustawia pominięte askFallback na deny. Ustaw hostowe askFallback jawnie na full, gdy monit zatwierdzenia bez interfejsu użytkownika ma awaryjnie zezwalać.
WarstwaUstawienie YOLO
tools.exec.securityfull na gateway/node
tools.exec.askoff
Host askFallbackfull
Ważne rozróżnienia:
  • tools.exec.host=auto wybiera gdzie działa exec: piaskownica, gdy jest dostępna, w przeciwnym razie gateway.
  • YOLO wybiera jak zatwierdzany jest exec hosta: security=full plus ask=off.
  • W trybie YOLO OpenClaw nie dodaje osobnej heurystycznej bramki zatwierdzania zaciemniania poleceń ani warstwy odrzucania skryptów przed wykonaniem na wierzchu skonfigurowanej polityki exec hosta.
  • auto nie czyni routingu Gateway swobodnym nadpisaniem z sesji w piaskownicy. Żądanie per wywołanie host=node jest dozwolone z auto; host=gateway jest dozwolone z auto tylko wtedy, gdy żadne środowisko uruchomieniowe piaskownicy nie jest aktywne. Aby uzyskać stabilne ustawienie domyślne inne niż auto, ustaw tools.exec.host albo użyj jawnie /exec host=....
Dostawcy wspierani przez CLI, którzy udostępniają własny nieinteraktywny tryb uprawnień, mogą stosować tę politykę. Claude CLI dodaje --permission-mode bypassPermissions, gdy efektywna polityka exec OpenClaw to YOLO. W przypadku sesji live Claude zarządzanych przez OpenClaw efektywna polityka exec OpenClaw jest nadrzędna wobec natywnego trybu uprawnień Claude: YOLO normalizuje uruchomienia live do --permission-mode bypassPermissions, a restrykcyjna efektywna polityka exec normalizuje uruchomienia live do --permission-mode default, nawet jeśli surowe argumenty backendu Claude określają inny tryb. Jeśli chcesz bardziej konserwatywnej konfiguracji, zaostrz politykę exec OpenClaw z powrotem do allowlist / on-miss albo deny.

​
Trwała konfiguracja hosta Gateway „nigdy nie pytaj”

1

Ustaw żądaną politykę konfiguracji

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart
2

Dopasuj plik zatwierdzeń hosta

openclaw approvals set --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

​
Lokalny skrót

openclaw exec-policy preset yolo
Ten lokalny skrót aktualizuje oba elementy:
  • Lokalne tools.exec.host/security/ask.
  • Domyślne wartości lokalnego pliku zatwierdzeń, w tym askFallback: "full".
Jest on celowo tylko lokalny. Aby zdalnie zmienić zatwierdzenia hosta Gateway lub hosta węzła, użyj openclaw approvals set --gateway albo openclaw approvals set --node <id|name|ip>.

​
Host węzła

Dla hosta węzła zastosuj zamiast tego ten sam plik zatwierdzeń na tym węźle: 
openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF
Ograniczenia tylko lokalne:
  • openclaw exec-policy nie synchronizuje zatwierdzeń węzła.
  • openclaw exec-policy set --host node jest odrzucane.
  • Zatwierdzenia exec węzła są pobierane z węzła w czasie działania, więc aktualizacje kierowane do węzła muszą używać openclaw approvals --node ....

​
Skrót tylko dla sesji

  • /exec security=full ask=off zmienia tylko bieżącą sesję.
  • /elevated full to awaryjny skrót, który pomija zatwierdzenia exec tylko wtedy, gdy zarówno żądana polityka, jak i plik zatwierdzeń hosta rozpoznają się jako security: "full" i ask: "off". Surowszy plik hosta, taki jak ask: "always", nadal wyświetla monit.
Jeśli plik zatwierdzeń hosta pozostaje surowszy niż konfiguracja, surowsza polityka hosta nadal wygrywa.

​
Lista dozwolonych (na agenta)

Listy dozwolonych są na agenta. Jeśli istnieje wielu agentów, przełącz w aplikacji macOS, którego agenta edytujesz. Wzorce są dopasowaniami glob. Wzorce mogą być globami rozpoznanych ścieżek binarnych albo gołymi globami nazw poleceń. Gołe nazwy pasują tylko do poleceń wywoływanych przez PATH, więc rg może pasować do /opt/homebrew/bin/rg, gdy poleceniem jest rg, ale nie do ./rg ani /tmp/rg. Użyj globu ścieżki, gdy chcesz zaufać jednej konkretnej lokalizacji pliku binarnego. Starsze wpisy agents.default są migrowane do agents.main podczas ładowania. Łańcuchy powłoki, takie jak echo ok && pwd, nadal wymagają, aby każdy segment najwyższego poziomu spełniał reguły listy dozwolonych. Przykłady:
  • rg
  • ~/Projects/**/bin/peekaboo
  • ~/.local/bin/*
  • /opt/homebrew/bin/rg

​
Ograniczanie argumentów za pomocą argPattern

Dodaj argPattern, gdy wpis listy dozwolonych ma pasować do pliku binarnego i konkretnego kształtu argumentów. OpenClaw ocenia wyrażenie regularne względem przeanalizowanych argumentów polecenia, z wyłączeniem tokenu wykonywalnego (argv[0]). W przypadku wpisów pisanych ręcznie argumenty są łączone pojedynczą spacją, więc zakotwicz wzorzec, gdy potrzebujesz dokładnego dopasowania. 
{
  "version": 1,
  "agents": {
    "main": {
      "allowlist": [
        {
          "pattern": "python3",
          "argPattern": "^safe\\.py$"
        }
      ]
    }
  }
}
Ten wpis zezwala na python3 safe.py; python3 other.py nie trafia w listę dozwolonych. Jeśli istnieje też wpis tylko ze ścieżką dla tego samego pliku binarnego, niedopasowane argumenty mogą nadal wrócić do tego wpisu tylko ze ścieżką. Pomiń wpis tylko ze ścieżką, gdy celem jest ograniczenie pliku binarnego do zadeklarowanych argumentów. Wpisy zapisane przez przepływy zatwierdzania mogą używać wewnętrznego formatu separatora do dokładnego dopasowywania argv. Preferuj UI albo przepływ zatwierdzania, aby ponownie wygenerować te wpisy, zamiast ręcznie edytować zakodowaną wartość. Jeśli OpenClaw nie może przeanalizować argv dla segmentu polecenia, wpisy z argPattern nie pasują. Każdy wpis listy dozwolonych obsługuje:
PoleZnaczenie
patternGlob rozpoznanej ścieżki binarnej albo goły glob nazwy polecenia
argPatternOpcjonalny regex argv; pominięte wpisy są tylko ścieżkami
idStabilny UUID używany do tożsamości w UI
sourceŹródło wpisu, takie jak allow-always
commandTextTekst polecenia przechwycony, gdy przepływ zatwierdzania utworzył wpis
lastUsedAtZnacznik czasu ostatniego użycia
lastUsedCommandOstatnie polecenie, które pasowało
lastResolvedPathOstatnia rozpoznana ścieżka binarna

​
Automatyczne zezwalanie na CLI Skills

Gdy Automatyczne zezwalanie na CLI Skills jest włączone, pliki wykonywalne wskazywane przez znane Skills są traktowane jako dozwolone na Node (Node macOS albo bezgłowy host Node). Używa to skills.bins przez Gateway RPC, aby pobrać listę binariów Skills. Wyłącz to, jeśli chcesz mieć ściśle ręczne listy dozwolonych.
  • To jest niejawna wygodna lista dozwolonych, oddzielna od ręcznych wpisów listy dozwolonych ścieżek.
  • Jest przeznaczona dla zaufanych środowisk operatorów, w których Gateway i Node są w tej samej granicy zaufania.
  • Jeśli wymagasz ściśle jawnego zaufania, zachowaj autoAllowSkills: false i używaj tylko ręcznych wpisów listy dozwolonych ścieżek.

​
Bezpieczne binaria i przekazywanie zatwierdzeń

Informacje o bezpiecznych binariach (szybka ścieżka tylko przez stdin), szczegółach wiązania interpreterów oraz o tym, jak przekazywać monity zatwierdzeń do Slack/Discord/Telegram (albo uruchamiać je jako natywnych klientów zatwierdzeń), znajdziesz w Zatwierdzenia exec - zaawansowane.

​
Edytowanie w Control UI

Użyj karty Control UI → Node → Zatwierdzenia exec, aby edytować wartości domyślne, nadpisania na agenta i listy dozwolonych. Wybierz zakres (Domyślne albo agent), dostosuj politykę, dodaj/usuń wzorce listy dozwolonych, a potem wybierz Zapisz. UI pokazuje metadane ostatniego użycia dla każdego wzorca, aby można było utrzymać listę w porządku. Selektor celu wybiera Gateway (zatwierdzenia lokalne) albo Node. Node muszą ogłaszać system.execApprovals.get/set (aplikacja macOS albo bezgłowy host Node). Jeśli Node jeszcze nie ogłasza zatwierdzeń exec, edytuj bezpośrednio jego lokalny plik zatwierdzeń. CLI: openclaw approvals obsługuje edytowanie Gateway albo Node - zobacz CLI zatwierdzeń.

​
Przepływ zatwierdzania

Gdy wymagany jest monit, Gateway rozgłasza exec.approval.requested do klientów operatora. Control UI i aplikacja macOS rozwiązują go przez exec.approval.resolve, a następnie Gateway przekazuje zatwierdzone żądanie do hosta Node. Dla host=node żądania zatwierdzenia zawierają kanoniczny payload systemRunPlan. Gateway używa tego planu jako autorytatywnego kontekstu command/cwd/session podczas przekazywania zatwierdzonych żądań system.run. Ma to znaczenie dla opóźnień zatwierdzeń asynchronicznych:
  • Ścieżka exec Node przygotowuje z góry jeden kanoniczny plan.
  • Rekord zatwierdzenia przechowuje ten plan i jego metadane wiązania.
  • Po zatwierdzeniu końcowe przekazane wywołanie system.run ponownie używa zapisanego planu, zamiast ufać późniejszym edycjom wywołującego.
  • Jeśli wywołujący zmieni command, rawCommand, cwd, agentId albo sessionKey po utworzeniu żądania zatwierdzenia, Gateway odrzuca przekazane uruchomienie jako niezgodność zatwierdzenia.

​
Zdarzenia systemowe

Cykl życia exec jest pokazywany jako komunikaty systemowe:
  • Exec running (tylko jeśli polecenie przekroczy próg powiadomienia o działaniu).
  • Exec finished.
Są one publikowane w sesji agenta po zgłoszeniu zdarzenia przez Node. Odmówione zatwierdzenia exec są terminalne dla samego polecenia hosta: polecenie nie zostaje uruchomione. W przypadku asynchronicznych zatwierdzeń głównego agenta z sesją źródłową OpenClaw publikuje odmowę z powrotem do tej sesji jako wewnętrzną kontynuację, aby agent mógł przestać czekać na polecenie asynchroniczne i uniknąć naprawy brakującego wyniku. Jeśli nie ma sesji albo sesji nie można wznowić, OpenClaw nadal może zgłosić zwięzłą odmowę operatorowi albo bezpośredniej trasie czatu. Odmowy dla sesji subagentów nie są publikowane z powrotem do subagenta. Zatwierdzenia exec hostowane przez Gateway emitują te same zdarzenia cyklu życia, gdy polecenie się kończy (i opcjonalnie, gdy działa dłużej niż próg). Exec ograniczone zatwierdzeniem ponownie używają id zatwierdzenia jako runId w tych komunikatach, aby ułatwić korelację.

​
Zachowanie przy odmowie zatwierdzenia

Gdy asynchroniczne zatwierdzenie exec zostanie odmówione, OpenClaw traktuje polecenie hosta jako terminalne i zamknięte odmową. W sesjach głównego agenta odmowa jest dostarczana jako wewnętrzna kontynuacja sesji, która mówi agentowi, że polecenie asynchroniczne nie zostało uruchomione. Zachowuje to ciągłość transkryptu bez ujawniania nieaktualnego wyjścia polecenia. Jeśli dostarczenie do sesji jest niedostępne, OpenClaw wraca do zwięzłej odmowy dla operatora albo bezpośredniego czatu, gdy istnieje bezpieczna trasa.

​
Implikacje

  • full jest potężne; preferuj listy dozwolonych, gdy to możliwe.
  • ask utrzymuje cię w obiegu, a jednocześnie pozwala na szybkie zatwierdzenia.
  • Listy dozwolonych na agenta zapobiegają przeciekaniu zatwierdzeń jednego agenta do innych.
  • Zatwierdzenia dotyczą tylko żądań exec hosta od autoryzowanych nadawców. Nieautoryzowani nadawcy nie mogą wywołać /exec.
  • /exec security=full to wygoda na poziomie sesji dla autoryzowanych operatorów i z założenia pomija zatwierdzenia. Aby twardo zablokować exec hosta, ustaw zabezpieczenia zatwierdzeń na deny albo odmów narzędzia exec przez politykę narzędzi.

​
Powiązane

Exec approvals - advanced

Bezpieczne binaria, wiązanie interpreterów i przekazywanie zatwierdzeń do czatu.

Exec tool

Narzędzie wykonywania poleceń powłoki.

Elevated mode

Ścieżka awaryjna, która również pomija zatwierdzenia.

Sandboxing

Tryby piaskownicy i dostęp do obszaru roboczego.

Security

Model bezpieczeństwa i utwardzanie.

Sandbox vs tool policy vs elevated

Kiedy sięgać po każdą kontrolę.

Skills

Zachowanie automatycznego zezwalania oparte na Skills.