​

Zatwierdzenia exec

​

Gdzie to ma zastosowanie

• host gateway → proces openclaw na maszynie gateway
• host node → runner node (aplikacja towarzysząca macOS albo headless host node)

• Wywołujący uwierzytelnieni przez Gateway są zaufanymi operatorami tego Gateway.
• Sparowane node’y rozszerzają tę możliwość zaufanego operatora na host node.
• Zatwierdzenia exec zmniejszają ryzyko przypadkowego wykonania, ale nie są granicą auth per użytkownik.
• Zatwierdzone uruchomienia na hoście node wiążą kanoniczny kontekst wykonania: kanoniczne cwd, dokładne argv, powiązanie env, gdy występuje, oraz przypiętą ścieżkę wykonywalną, gdy ma zastosowanie.
• Dla skryptów shell i bezpośrednich wywołań plików interpretera/runtime OpenClaw także próbuje powiązać jeden konkretny lokalny operand pliku. Jeśli ten powiązany plik zmieni się po zatwierdzeniu, ale przed wykonaniem, uruchomienie zostaje odrzucone zamiast wykonywać zdryfowaną treść.
• To powiązanie pliku jest celowo best-effort, a nie pełnym semantycznym modelem każdej ścieżki ładowania interpretera/runtime. Jeśli tryb zatwierdzania nie potrafi zidentyfikować dokładnie jednego konkretnego lokalnego pliku do powiązania, odmawia wystawienia uruchomienia opartego na zatwierdzeniu zamiast udawać pełne pokrycie.

• usługa hosta node przekazuje system.run do aplikacji macOS przez lokalne IPC.
• aplikacja macOS egzekwuje zatwierdzenia + wykonuje polecenie w kontekście UI.

​

Ustawienia i storage

{
  "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",
          "lastUsedAt": 1737150000000,
          "lastUsedCommand": "rg -n TODO",
          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"
        }
      ]
    }
  }
}

​

Tryb “YOLO” bez zatwierdzeń

• żądaną politykę exec w config OpenClaw (tools.exec.*)
• lokalną politykę zatwierdzeń hosta w ~/.openclaw/exec-approvals.json

• tools.exec.security: full na gateway/node
• tools.exec.ask: off
• host askFallback: full

• tools.exec.host=auto wybiera miejsce uruchamiania exec: sandbox, jeśli jest dostępny, w przeciwnym razie gateway.
• YOLO wybiera sposób zatwierdzania exec na hoście: security=full plus ask=off.
• W trybie YOLO OpenClaw nie dodaje osobnej heurystycznej bramki zatwierdzeń dla maskowania poleceń ani warstwy odrzucania preflight skryptów ponad skonfigurowaną politykę exec hosta.
• auto nie czyni routowania do gateway darmowym nadpisaniem z sandboxowanej sesji. Żądanie per call host=node jest dozwolone z auto, a host=gateway jest dozwolone z auto tylko wtedy, gdy nie ma aktywnego runtime sandbox. Jeśli chcesz stabilnej domyślnej wartości nie-auto, ustaw tools.exec.host albo użyj jawnie /exec host=....

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

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

openclaw exec-policy preset yolo

• lokalne tools.exec.host/security/ask
• lokalne domyślne ustawienia ~/.openclaw/exec-approvals.json

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

• openclaw exec-policy nie synchronizuje zatwierdzeń node
• openclaw exec-policy set --host node jest odrzucane
• zatwierdzenia exec node są pobierane z node w runtime, więc aktualizacje kierowane do node muszą używać openclaw approvals --node ...

• /exec security=full ask=off zmienia tylko bieżącą sesję.
• /elevated full to awaryjny skrót break-glass, który także pomija zatwierdzenia exec dla tej sesji.

​

Pokrętła polityki

​

Security (exec.security)

• deny: blokuje wszystkie żądania exec na hoście.
• allowlist: zezwala tylko na polecenia z allowlist.
• full: zezwala na wszystko (równoważne elevated).

​

Ask (exec.ask)

• off: nigdy nie pokazuj promptu.
• on-miss: pytaj tylko wtedy, gdy allowlist nie pasuje.
• always: pytaj przy każdym poleceniu.
• trwałe zaufanie allow-always nie tłumi promptów, gdy efektywny tryb ask to always

​

Ask fallback (askFallback)

• deny: blokuj.
• allowlist: zezwól tylko, jeśli allowlist pasuje.
• full: zezwól.

​

Utwardzanie inline eval interpretera (tools.exec.strictInlineEval)

• python -c
• node -e, node --eval, node -p
• ruby -e
• perl -e, perl -E
• php -r
• lua -e
• osascript -e

• te polecenia nadal wymagają jawnego zatwierdzenia;
• allow-always nie utrwala dla nich automatycznie nowych wpisów allowlist.

​

Allowlist (per agent)

• ~/Projects/**/bin/peekaboo
• ~/.local/bin/*
• /opt/homebrew/bin/rg

• id stabilne UUID używane do tożsamości w UI (opcjonalne)
• last used znacznik czasu
• last used command
• last resolved path

​

Auto-allow CLI Skills

• To niejawna wygodna allowlist, oddzielna od ręcznych wpisów allowlist ścieżek.
• Jest przeznaczona do zaufanych środowisk operatora, gdzie Gateway i node są w tej samej granicy zaufania.
• Jeśli potrzebujesz ścisłego jawnego zaufania, pozostaw autoAllowSkills: false i używaj tylko ręcznych wpisów allowlist ścieżek.

​

Safe bins (tylko stdin)

• grep: --dereference-recursive, --directories, --exclude-from, --file, --recursive, -R, -d, -f, -r
• jq: --argfile, --from-file, --library-path, --rawfile, --slurpfile, -L, -f
• sort: --compress-program, --files0-from, --output, --random-source, --temporary-directory, -T, -o
• wc: --files0-from

​

Safe bins versus allowlist

• safeBins pochodzi z config (tools.exec.safeBins albo per agent agents.list[].tools.exec.safeBins).
• safeBinTrustedDirs pochodzi z config (tools.exec.safeBinTrustedDirs albo per agent agents.list[].tools.exec.safeBinTrustedDirs).
• safeBinProfiles pochodzi z config (tools.exec.safeBinProfiles albo per agent agents.list[].tools.exec.safeBinProfiles). Klucze profili per agent nadpisują klucze globalne.
• wpisy allowlist znajdują się w lokalnym dla hosta ~/.openclaw/exec-approvals.json pod agents.<id>.allowlist (albo przez Control UI / openclaw approvals allowlist ...).
• openclaw security audit ostrzega tools.exec.safe_bins_interpreter_unprofiled, gdy binarki interpreterów/runtime pojawiają się w safeBins bez jawnych profili.
• openclaw doctor --fix może przygotować brakujące wpisy niestandardowe safeBinProfiles.<bin> jako {} (potem je przejrzyj i zaostrz). Binarki interpreterów/runtime nie są przygotowywane automatycznie.

​

Edycja w Control UI

​

Przepływ zatwierdzania

• ścieżka exec node przygotowuje z góry jeden kanoniczny plan
• rekord zatwierdzenia przechowuje ten plan i jego metadane powiązania
• po zatwierdzeniu końcowe przekazane wywołanie system.run używa ponownie przechowanego planu zamiast ufać późniejszym zmianom wywołującego
• jeśli wywołujący zmieni command, rawCommand, cwd, agentId albo sessionKey po utworzeniu żądania zatwierdzenia, gateway odrzuca przekazane uruchomienie jako niedopasowanie zatwierdzenia

​

Polecenia interpretera/runtime

• Dokładny kontekst argv/cwd/env jest zawsze wiązany.
• Bezpośrednie formy skryptów shell i bezpośrednich plików runtime są best-effort wiązane z jedną konkretną lokalną migawką pliku.
• Typowe formy wrapperów package managera, które nadal rozwiązują się do jednego bezpośredniego lokalnego pliku (na przykład pnpm exec, pnpm node, npm exec, npx), są rozwijane przed powiązaniem.
• Jeśli OpenClaw nie potrafi zidentyfikować dokładnie jednego konkretnego lokalnego pliku dla polecenia interpretera/runtime (na przykład skrypty pakietów, formy eval, łańcuchy loaderów specyficzne dla runtime albo niejednoznaczne formy wieloplikowe), wykonanie oparte na zatwierdzeniu jest odrzucane zamiast twierdzić, że pokrywa semantykę, której faktycznie nie ma.
• Dla takich przepływów preferuj sandboxing, oddzielną granicę hosta albo jawny zaufany przepływ allowlist/full, w którym operator akceptuje szerszą semantykę runtime.

​

Zachowanie dostarczania follow-up

• Jeśli istnieje poprawny zewnętrzny cel dostarczania (dostarczalny kanał plus cel to), dostarczanie follow-up używa tego kanału.
• W przepływach tylko webchat albo sesji wewnętrznych bez celu zewnętrznego dostarczanie follow-up pozostaje tylko sesyjne (deliver: false).
• Jeśli wywołujący jawnie żąda ścisłego zewnętrznego dostarczenia bez rozwiązywalnego zewnętrznego kanału, żądanie kończy się błędem INVALID_REQUEST.
• Jeśli włączone jest bestEffortDeliver i nie można rozwiązać żadnego zewnętrznego kanału, dostarczanie jest degradowane do tylko sesyjnego zamiast kończyć się błędem.

• polecenie + argumenty
• cwd
• identyfikator agenta
• rozwiązaną ścieżkę pliku wykonywalnego
• metadane hosta + polityki

• Allow once → uruchom teraz
• Always allow → dodaj do allowlist + uruchom
• Deny → zablokuj

​

Przekazywanie zatwierdzeń do kanałów czatu

​

Przekazywanie zatwierdzeń pluginów

​

Zatwierdzenia w tym samym czacie na dowolnym kanale

​

Natywne dostarczanie zatwierdzeń

• polityka exec hosta nadal decyduje, czy zatwierdzenie exec jest wymagane
• approvals.exec kontroluje przekazywanie promptów zatwierdzeń do innych miejsc docelowych czatu
• channels.<channel>.execApprovals kontroluje, czy dany kanał działa jako natywny klient zatwierdzeń

• kanał obsługuje natywne dostarczanie zatwierdzeń
• zatwierdzający mogą zostać rozwiązani z jawnego execApprovals.approvers albo z udokumentowanych źródeł zapasowych danego kanału
• channels.<channel>.execApprovals.enabled jest nieustawione albo ma wartość "auto"

• Discord: channels.discord.execApprovals.*
• Slack: channels.slack.execApprovals.*
• Telegram: channels.telegram.execApprovals.*

• Slack, Matrix, Microsoft Teams i podobne dostarczalne czaty używają normalnego modelu auth kanału dla /approve w tym samym czacie
• gdy natywny klient zatwierdzeń włącza się automatycznie, domyślnym natywnym celem dostarczenia są DM zatwierdzających
• dla Discord i Telegram tylko rozwiązani zatwierdzający mogą zatwierdzać albo odrzucać
• zatwierdzający Discord mogą być jawni (execApprovals.approvers) albo wywnioskowani z commands.ownerAllowFrom
• zatwierdzający Telegram mogą być jawni (execApprovals.approvers) albo wywnioskowani z istniejącej konfiguracji właściciela (allowFrom, plus defaultTo wiadomości bezpośrednich tam, gdzie jest obsługiwane)
• zatwierdzający Slack mogą być jawni (execApprovals.approvers) albo wywnioskowani z commands.ownerAllowFrom
• natywne przyciski Slack zachowują rodzaj identyfikatora zatwierdzenia, więc identyfikatory plugin: mogą rozwiązywać zatwierdzenia pluginów bez drugiej lokalnej warstwy fallback Slack
• natywne routowanie DM/kanału Matrix i skróty reakcji obsługują zarówno zatwierdzenia exec, jak i pluginów; autoryzacja pluginów nadal pochodzi z channels.matrix.dm.allowFrom
• żądający nie musi być zatwierdzającym
• czat źródłowy może zatwierdzić bezpośrednio przez /approve, gdy ten czat już obsługuje polecenia i odpowiedzi
• natywne przyciski zatwierdzeń Discord routują według rodzaju identyfikatora zatwierdzenia: identyfikatory plugin: trafiają bezpośrednio do zatwierdzeń pluginów, wszystko inne trafia do zatwierdzeń exec
• natywne przyciski zatwierdzeń Telegram stosują ten sam ograniczony fallback exec-do-plugin co /approve
• gdy natywne target włącza dostarczanie do czatu źródłowego, prompty zatwierdzeń zawierają tekst polecenia
• oczekujące zatwierdzenia exec domyślnie wygasają po 30 minutach
• jeśli żadne UI operatora ani skonfigurowany klient zatwierdzeń nie może przyjąć żądania, prompt przechodzi zapasowo do askFallback

• Discord
• Telegram

​

Przepływ IPC macOS

• Tryb gniazda Unix 0600, token przechowywany w exec-approvals.json.
• Sprawdzenie peera o tym samym UID.
• Challenge/response (nonce + token HMAC + hash żądania) + krótki TTL.

​

Zdarzenia systemowe

• Exec running (tylko jeśli polecenie przekroczy próg powiadomienia o uruchomieniu)
• Exec finished
• Exec denied

​

Zachowanie przy odrzuconym zatwierdzeniu

​

Konsekwencje

• full jest potężne; gdy to możliwe, preferuj allowlisty.
• ask utrzymuje Cię w pętli, jednocześnie umożliwiając szybkie zatwierdzenia.
• Allowlisty per agent zapobiegają wyciekaniu zatwierdzeń jednego agenta do innych.
• Zatwierdzenia mają zastosowanie tylko do żądań exec na hoście od autoryzowanych nadawców. Nieautoryzowani nadawcy nie mogą wydawać /exec.
• /exec security=full to wygodne ustawienie na poziomie sesji dla autoryzowanych operatorów i z założenia pomija zatwierdzenia. Aby twardo zablokować exec na hoście, ustaw security zatwierdzeń na deny albo zablokuj narzędzie exec przez politykę narzędzi.

• Narzędzie Exec
• Tryb Elevated
• Skills

​

Powiązane

• Exec — narzędzie wykonywania poleceń shell
• Sandboxing — tryby sandboxa i dostęp do workspace
• Bezpieczeństwo — model bezpieczeństwa i utwardzanie
• Sandbox vs Tool Policy vs Elevated — kiedy używać którego