plugin.approval.* oraz tych samych powierzchni UI zatwierdzania, które obsługują przyciski zatwierdzania w czacie i polecenia /approve.
Używaj żądań uprawnień Plugin do uprawnień Plugin/aplikacji. Nie zastępują one zatwierdzeń wykonywania poleceń hosta, opcjonalnych list dozwolonych narzędzi ani natywnego przeglądu uprawnień Codex.
Wybierz właściwą bramkę
Wybierz bramkę pasującą do punktu decyzyjnego, którego potrzebujesz:| Bramka | Użyj jej, gdy | Co kontroluje |
|---|---|---|
| Opcjonalne narzędzia | Narzędzie nie powinno być widoczne dla modelu, dopóki użytkownik go nie włączy. | Ekspozycję narzędzi przez tools.allow. |
| Żądania uprawnień Plugin | Hook Plugin lub operacja należąca do Plugin musi zapytać przed wykonaniem jednej akcji. | Zatwierdzanie w czasie działania przez plugin.approval.*. |
| Zatwierdzenia exec | Polecenie hosta lub narzędzie podobne do powłoki wymaga zatwierdzenia operatora. | Politykę exec hosta i trwałe listy dozwolonych exec. |
| Natywne żądania uprawnień Codex | Codex pyta przed natywnymi akcjami powłoki, plików, MCP lub serwera aplikacji. | Obsługę zatwierdzania serwera aplikacji Codex lub natywnego hooka, kierowaną przez zatwierdzenia Plugin, gdy OpenClaw jest właścicielem promptu. |
| Wywołania zatwierdzeń MCP | Serwer MCP Codex żąda zatwierdzenia wywołania narzędzia. | Odpowiedzi zatwierdzeń MCP przekazywane przez zatwierdzenia Plugin OpenClaw. |
Żądaj zatwierdzenia przed wywołaniem narzędzia
Większość promptów tworzonych przez Plugin powinna zaczynać się w hookubefore_tool_call. Hook działa po tym, jak model wybierze narzędzie, a przed tym, jak OpenClaw je wykona:
titlepowinien być krótki i skupiony na akcji. Gateway akceptuje do 80 znaków.descriptionpowinien być konkretny i ograniczony zakresem. Gateway akceptuje do 256 znaków.- Uwzględnij akcję, cel i ryzyko. Nie uwzględniaj sekretów, tokenów ani prywatnych danych, które nie powinny pojawić się na powierzchniach zatwierdzania w czacie.
- Używaj
severity: "critical"tylko dla akcji, przy których błędna decyzja może spowodować szkody produkcyjne lub utratę danych. - Używaj
allowedDecisions: ["allow-once", "deny"], gdy trwałe zaufanie jest niebezpieczne dla tej akcji.
Zachowanie decyzji
OpenClaw tworzy oczekujące zatwierdzenie z IDplugin:, dostarcza je do dostępnych powierzchni zatwierdzania i czeka na decyzję.
| Decyzja | Wynik |
|---|---|
allow-once | Bieżące wywołanie jest kontynuowane. |
allow-always | Bieżące wywołanie jest kontynuowane, a decyzja jest przekazywana do Plugin. |
deny | Wywołanie jest blokowane z wynikiem narzędzia oznaczającym odmowę. |
| Przekroczenie czasu | Wywołanie jest blokowane, chyba że timeoutBehavior ma wartość "allow". |
| Anulowanie | Wywołanie jest blokowane, gdy przebieg zostanie przerwany. |
| Brak ścieżki zatwierdzenia | Wywołanie jest blokowane, ponieważ żadna połączona powierzchnia zatwierdzania nie może go rozstrzygnąć. |
allow-always jest trwałe tylko wtedy, gdy żądający Plugin lub runtime implementuje tę trwałość. Dla zwykłych hooków before_tool_call.requireApproval OpenClaw traktuje allow-once i allow-always jako decyzje zatwierdzające dla bieżącego wywołania i przekazuje rozstrzygniętą wartość do onResolution. Jeśli Twój Plugin oferuje allow-always, udokumentuj i zaimplementuj dokładnie, którym przyszłym wywołaniom ufa.
Jeśli hook zwraca także params, OpenClaw stosuje te zmiany parametrów dopiero po pomyślnym zatwierdzeniu. Hook o niższym priorytecie nadal może zablokować wywołanie po tym, jak hook o wyższym priorytecie zażądał zatwierdzenia.
allowedDecisions ogranicza przyciski i polecenia pokazywane użytkownikowi. Gateway odrzuca próbę rozstrzygnięcia dla każdej decyzji, której żądanie nie oferowało.
Kieruj prompty zatwierdzania
Prompty zatwierdzania mogą być rozstrzygane w lokalnych powierzchniach UI albo w kanałach czatu obsługujących zatwierdzanie. Aby przekazywać prompty zatwierdzania Plugin do jawnych celów czatu, skonfigurujapprovals.plugin:
approvals.plugin jest niezależne od approvals.exec. Włączenie przekazywania zatwierdzeń exec nie kieruje promptów zatwierdzania Plugin, a włączenie przekazywania zatwierdzeń Plugin nie zmienia polityki exec hosta.
Gdy prompt zawiera ręczny tekst zatwierdzania, rozstrzygnij go jedną z oferowanych decyzji:
Natywne uprawnienia Codex
Natywne prompty uprawnień Codex mogą również przechodzić przez zatwierdzenia Plugin, ale mają inną własność niż hooki tworzone przez Plugin.- Żądania zatwierdzenia serwera aplikacji Codex są kierowane przez OpenClaw po przeglądzie Codex.
- Natywny przekaźnik hooka
permission_requestmoże pytać przezplugin.approval.request, gdy ten przekaźnik jest włączony. - Wywołania zatwierdzeń narzędzi MCP są kierowane przez zatwierdzenia Plugin, gdy Codex oznaczy
_meta.codex_approval_kindjako"mcp_tool_call".
Rozwiązywanie problemów
Narzędzie informuje, że zatwierdzenia Plugin są niedostępne. Żaden UI zatwierdzania ani skonfigurowana ścieżka zatwierdzenia nie zaakceptowała żądania. Podłącz klienta obsługującego zatwierdzanie, użyj kanału obsługującego/approve w tym samym czacie albo skonfiguruj approvals.plugin.
Pojawia się allow-always, ale następne wywołanie ponownie pokazuje prompt. Ogólny przepływ zatwierdzania Plugin nie utrwala automatycznie zaufania dla dowolnych hooków. Utrwal zaufanie należące do Plugin w swoim Plugin po onResolution("allow-always") albo oferuj tylko allow-once i deny.
/approve odrzuca decyzję. Żądanie ograniczyło allowedDecisions. Użyj jednej z decyzji wypisanych w prompcie.
Prompt Slack, Discord, Telegram lub Matrix jest kierowany inaczej niż zatwierdzenia exec. Zatwierdzenia Plugin i zatwierdzenia exec używają oddzielnej konfiguracji i mogą używać różnych kontroli autoryzacji. Zweryfikuj approvals.plugin oraz obsługę zatwierdzeń Plugin w kanale zamiast sprawdzać tylko approvals.exec.