Ausführungsgenehmigungen

Exec-Genehmigungen sind die Schutzvorkehrung der Begleit-App/des Node-Hosts, mit der ein isolierter Agent Befehle auf einem realen Host (gateway oder node) ausführen darf. Befehle werden nur ausgeführt, wenn Richtlinie, Zulassungsliste und (optional) die Benutzergenehmigung übereinstimmen. Genehmigungen gelten zusätzlich zu Tool-Richtlinien und Elevated-Zugriffskontrollen (Elevated full überspringt sie).

Eine modusorientierte Übersicht über deny, allowlist, ask, auto, full, die Zuordnung zu Codex Guardian und ACPX-Harness-Berechtigungen finden Sie unter Berechtigungsmodi.

Geltungsbereich

Exec-Genehmigungen werden lokal auf dem Ausführungshost erzwungen:

• Gateway-Host -> openclaw-Prozess auf dem Gateway-Computer.
• Node-Host -> Node-Runner (macOS-Begleit-App oder monitorloser Node-Host).

Vertrauensmodell

• Über den Gateway authentifizierte Aufrufer sind vertrauenswürdige Operatoren für diesen Gateway.
• Gekoppelte Nodes erweitern diese Fähigkeit vertrauenswürdiger Operatoren auf den Node-Host.
• Genehmigungen verringern das Risiko einer unbeabsichtigten Ausführung, sind aber keine benutzerspezifische Authentifizierungsgrenze oder schreibgeschützte Dateisystemrichtlinie.
• Nach der Genehmigung kann ein Befehl Dateien entsprechend den ausgewählten Host- oder Sandbox-Dateisystemberechtigungen verändern.
• Genehmigte Ausführungen auf Node-Hosts binden den kanonischen Ausführungskontext: Arbeitsverzeichnis, exakte Argumentliste, Umgebungsbindung, sofern vorhanden, und gegebenenfalls den festgelegten Pfad der ausführbaren Datei.
• Bei Shell-Skripten und direkten Datei-Aufrufen über Interpreter oder Laufzeiten versucht OpenClaw außerdem, einen konkreten lokalen Dateioperanden zu binden. Wenn sich diese Datei nach der Genehmigung, aber vor der Ausführung ändert, wird die Ausführung verweigert, statt den abweichenden Inhalt auszuführen.
• Die Dateibindung erfolgt nach bestem Bemühen und bildet nicht jeden Ladepfad eines Interpreters oder einer Laufzeit vollständig ab. Wenn nicht genau eine konkrete lokale Datei identifiziert werden kann, verweigert OpenClaw die Erstellung einer genehmigungsgestützten Ausführung, statt eine vollständige Abdeckung vorzutäuschen.

macOS-Aufteilung

• Der Node-Host-Dienst leitet system.run über lokale IPC an die macOS-App weiter.
• Die macOS-App erzwingt Genehmigungen und führt den Befehl im UI-Kontext aus.

Effektive Richtlinie prüfen

Die vollständige CLI-Referenz (Flags, JSON-Ausgabe, Hinzufügen/Entfernen von Einträgen der Zulassungsliste) finden Sie unter Genehmigungs-CLI.

Wenn ein lokaler Geltungsbereich host=node anfordert, meldet exec-policy show diesen Geltungsbereich zur Laufzeit als Node-verwaltet, statt die lokale Genehmigungsdatei als maßgebliche Quelle zu behandeln.

Wenn die Benutzeroberfläche der Begleit-App nicht verfügbar ist, wird jede Anfrage, die normalerweise eine Abfrage auslösen würde, anhand des Abfrage-Fallbacks entschieden (Standard: deny).

Einstellungen und Speicherung

Genehmigungen werden in einer lokalen JSON-Datei auf dem Ausführungshost gespeichert. Wenn OPENCLAW_STATE_DIR gesetzt ist, befindet sich die Datei in diesem Zustandsverzeichnis; andernfalls wird das standardmäßige OpenClaw-Zustandsverzeichnis verwendet:

$OPENCLAW_STATE_DIR/exec-approvals.json# andernfalls~/.openclaw/exec-approvals.json

Der standardmäßige Genehmigungs-Socket verwendet dasselbe Stammverzeichnis: $OPENCLAW_STATE_DIR/exec-approvals.sock oder ~/.openclaw/exec-approvals.sock, wenn die Variable nicht gesetzt ist.

Versionen vor 2026.6.6 speicherten die Datei immer unter ~/.openclaw. Wenn OPENCLAW_STATE_DIR auf ein anderes Verzeichnis verweist und im Standardverzeichnis noch eine Genehmigungsdatei vorhanden ist, führen Sie einmal direkt openclaw doctor --fix aus, um sie in das Zustandsverzeichnis zu importieren (das Original wird mit dem Suffix .migrated archiviert). Der interaktive Doctor kann den Import ebenfalls in einer Vorschau anzeigen und bestätigen. Automatisierte Reparaturausführungen bei Updates und der Gateway-Überwachung importieren niemals über Zustandsverzeichnisgrenzen hinweg: Ein temporäres Zustands- oder Staging-Verzeichnis darf die Genehmigungen der Standardinstallation nicht übernehmen. Dieselbe Grenze gilt für Importe der veralteten Datei plugin-binding-approvals.json in den gemeinsam genutzten SQLite-Zustand.

Beispielschema:

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

Richtlinieneinstellungen

tools.exec.mode

tools.exec.mode ist die bevorzugte normalisierte Richtlinienoberfläche für die Host-Ausführung:

Die veralteten Optionen tools.exec.security / tools.exec.ask werden weiterhin unterstützt und gelten weiterhin überall dort, wo mode in diesem Geltungsbereich nicht festgelegt ist.

exec.security

exec.ask

askFallback

tools.exec.strictInlineEval

Beispiele, die der strikte Modus erfasst: python -c, node -e/--eval/-p, ruby -e, perl -e/-E, php -r, lua -e, osascript -e (ebenso Inline-Formen von awk, sed, make, find -exec und xargs).

Im strikten Modus benötigen diese Befehle die Genehmigung durch den Prüfer oder eine ausdrückliche Genehmigung. Bei tools.exec.mode: "auto" kann der Prüfer eine einmalige Ausführung mit geringem Risiko genehmigen, wenn für den Befehl ein durchsetzbarer Plan vorliegt; andernfalls fragt OpenClaw einen Menschen. Genehmigungen für Codex app-server-Befehle, die auf den Prüfer-Fallback zurückfallen, erfordern die Bestätigung durch einen Menschen, da ihre Genehmigungsanfragen keine durchsetzbare, aufgelöste ausführbare Datei angeben. allow-always speichert keine neuen Positivlisteneinträge für Inline-Auswertungsbefehle.

tools.exec.commandHighlighting

Legen Sie dies global unter tools.exec.commandHighlighting oder pro Agent unter agents.list[].tools.exec.commandHighlighting fest.

YOLO-Modus (ohne Genehmigung)

Um die Ausführung auf dem Host ohne Genehmigungsaufforderungen zu ermöglichen, müssen Sie beide Richtlinienebenen öffnen: die angeforderte Ausführungsrichtlinie in der OpenClaw-Konfiguration (tools.exec.*) und die hostlokale Genehmigungsrichtlinie in der Genehmigungsdatei des Ausführungshosts.

Wenn askFallback nicht angegeben ist, wird standardmäßig deny verwendet. Setzen Sie askFallback auf dem Host explizit auf full, wenn eine Genehmigungsaufforderung ohne Benutzeroberfläche ersatzweise die Ausführung zulassen soll.

CLI-gestützte Provider, die einen eigenen nicht interaktiven Berechtigungsmodus bereitstellen, können dieser Richtlinie folgen. Die Claude CLI fügt --permission-mode bypassPermissions hinzu, wenn die effektive Ausführungsrichtlinie von OpenClaw YOLO ist. Bei von OpenClaw verwalteten Claude-Live-Sitzungen ist die effektive Ausführungsrichtlinie von OpenClaw gegenüber dem nativen Berechtigungsmodus von Claude maßgeblich: YOLO normalisiert Live-Starts auf --permission-mode bypassPermissions, und eine restriktive effektive Ausführungsrichtlinie normalisiert Live-Starts auf --permission-mode default, selbst wenn die unverarbeiteten Claude-Backend-Argumente einen anderen Modus angeben.

Wenn Sie eine konservativere Einrichtung wünschen, verschärfen Sie die OpenClaw-Ausführungsrichtlinie wieder auf allowlist / on-miss oder deny.

Dauerhafte „Nie nachfragen“-Einrichtung auf dem Gateway-Host

openclaw config set tools.exec.host gatewayopenclaw config set tools.exec.security fullopenclaw config set tools.exec.ask offopenclaw gateway restart

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

Lokale Kurzform

openclaw exec-policy preset yolo

Aktualisiert sowohl die lokalen Werte für tools.exec.host/security/ask als auch die Standardwerte der lokalen Genehmigungsdatei (einschließlich askFallback: "full"). Dies gilt absichtlich nur lokal. Um Genehmigungen für den Gateway-Host oder Node-Host remote zu ändern, verwenden Sie openclaw approvals set --gateway oder openclaw approvals set --node <id|name|ip>.

Weitere integrierte Voreinstellungen: cautious (host=gateway, security=allowlist, ask=on-miss, askFallback=deny) und deny-all (host=gateway, security=deny, ask=off, askFallback=deny). Wenden Sie sie auf dieselbe Weise an: openclaw exec-policy preset cautious.

Um einzelne Felder statt einer vollständigen Voreinstellung festzulegen, verwenden Sie openclaw exec-policy set --host <auto|sandbox|gateway|node> --security <deny|allowlist|full> --ask <off|on-miss|always> --ask-fallback <deny|allowlist|full> mit einer beliebigen Teilmenge dieser Flags.

Node-Host

Wenden Sie stattdessen dieselbe Genehmigungsdatei auf dem Node an:

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

Kurzform nur für die Sitzung

• /exec security=full ask=off ändert nur die aktuelle Sitzung.
• /elevated full ist eine Notfall-Kurzform, die Ausführungsgenehmigungen nur dann überspringt, wenn sowohl die angeforderte Richtlinie als auch die Genehmigungsdatei des Hosts zu security: "full" und ask: "off" aufgelöst werden. Bei einer strengeren Host-Datei, etwa ask: "always", wird weiterhin nachgefragt.

Wenn die Genehmigungsdatei des Hosts strenger als die Konfiguration bleibt, hat weiterhin die strengere Host-Richtlinie Vorrang.

Positivliste (pro Agent)

Positivlisten gelten pro Agent. Wenn mehrere Agenten vorhanden sind, wechseln Sie in der macOS-App zu dem Agenten, den Sie bearbeiten möchten. Muster werden als Globs abgeglichen.

Muster können Globs für aufgelöste Binärpfade oder reine Globs für Befehlsnamen sein. Reine Namen stimmen nur mit Befehlen überein, die über PATH aufgerufen werden. Daher kann rg mit /opt/homebrew/bin/rg übereinstimmen, wenn der Befehl rg lautet, aber nicht mit ./rg oder /tmp/rg. Verwenden Sie einen Pfad-Glob, um genau einem bestimmten Binärpfad zu vertrauen.

Veraltete agents.default-Einträge werden beim Laden zu agents.main migriert. Shell-Ketten wie echo ok && pwd erfordern weiterhin, dass jedes Segment der obersten Ebene die Regeln der Positivliste erfüllt.

Beispiele:

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

Argumente mit argPattern einschränken

Fügen Sie argPattern hinzu, wenn ein Positivlisteneintrag mit einer Binärdatei und einer bestimmten Argumentstruktur übereinstimmen soll. OpenClaw verwendet auf jedem Host die Semantik regulärer ECMAScript-Ausdrücke (JavaScript) und wertet den Ausdruck anhand der geparsten Befehlsargumente aus, wobei das ausführbare Token (argv[0]) ausgeschlossen wird. Bei manuell erstellten Einträgen werden Argumente mit einem einzelnen Leerzeichen verbunden. Verankern Sie daher das Muster, wenn Sie eine exakte Übereinstimmung benötigen.

{  "version": 1,  "agents": {    "main": {      "allowlist": [        {          "pattern": "python3",          "argPattern": "^safe\\.py$"        }      ]    }  }}

Dieser Eintrag erlaubt python3 safe.py; python3 other.py verfehlt die Positivliste. Wenn außerdem ein reiner Pfadeintrag für dieselbe Binärdatei vorhanden ist, können nicht übereinstimmende Argumente weiterhin auf diesen reinen Pfadeintrag zurückfallen. Lassen Sie den reinen Pfadeintrag weg, wenn die Binärdatei auf die angegebenen Argumente beschränkt werden soll.

Von Genehmigungsabläufen gespeicherte Einträge verwenden ein internes Trennzeichenformat für den exakten argv-Abgleich. Verwenden Sie vorzugsweise die Benutzeroberfläche oder den Genehmigungsablauf, um diese Einträge neu zu erzeugen, statt den codierten Wert manuell zu bearbeiten. Wenn OpenClaw argv für ein Befehlssegment nicht parsen kann, stimmen Einträge mit argPattern nicht überein.

Jeder Positivlisteneintrag unterstützt:

Skills-CLIs automatisch zulassen

Wenn Skills-CLIs automatisch zulassen (autoAllowSkills) aktiviert ist, werden ausführbare Dateien, auf die bekannte Skills verweisen, auf Nodes (macOS-Node oder Headless-Node-Host) als in der Positivliste enthalten behandelt. Dabei wird skills.bins über den Gateway-RPC verwendet, um die Liste der Skill-Binärdateien abzurufen. Deaktivieren Sie dies, wenn Sie strikte manuelle Positivlisten wünschen.

Sichere Binärdateien und Weiterleitung von Genehmigungen

Informationen zu sicheren Binärdateien (dem schnellen, ausschließlich stdin-basierten Pfad), Details zur Interpreter-Bindung und zur Weiterleitung von Genehmigungsaufforderungen an Slack/Discord/Telegram (oder deren Ausführung als native Genehmigungsclients) finden Sie unter Ausführungsgenehmigungen – erweitert.

Bearbeitung in der Control UI

Verwenden Sie die Karte Control UI -> Nodes -> Exec approvals, um Standardwerte, agentenspezifische Überschreibungen und Positivlisten zu bearbeiten. Wählen Sie einen Bereich (Defaults oder einen Agenten), passen Sie die Richtlinie an, fügen Sie Positivlistenmuster hinzu oder entfernen Sie sie und wählen Sie anschließend Save. Die Benutzeroberfläche zeigt für jedes Muster Metadaten zur letzten Verwendung an, damit Sie die Liste übersichtlich halten können.

Die Zielauswahl bestimmt Gateway (lokale Genehmigungen) oder einen Node. Nodes müssen system.execApprovals.get/set bereitstellen (macOS-App oder Headless- Node-Host). Wenn ein Node Ausführungsgenehmigungen noch nicht bereitstellt, bearbeiten Sie dessen lokale Genehmigungsdatei direkt.

Einige Node-Hosts, darunter die Windows-Begleitanwendung, verwenden ein anderes Format für Genehmigungsrichtlinien. Die Control UI zeigt diese hosteigenen Richtlinien schreibgeschützt an. Verwenden Sie die Begleitanwendung oder openclaw approvals set --node <id|name|ip> mit dem nativen Richtlinienformat, um sie zu bearbeiten; siehe Genehmigungs-CLI.

CLI: openclaw approvals unterstützt die Bearbeitung von Gateway oder Node – siehe Genehmigungs-CLI.

Genehmigungsablauf

Wenn eine Aufforderung erforderlich ist, sendet das Gateway exec.approval.requested an Betreiberclients. Die Control UI und die macOS- App lösen sie über exec.approval.resolve auf; anschließend leitet das Gateway die genehmigte Anfrage an den Node-Host weiter.

Für host=node enthalten Genehmigungsanfragen eine kanonische systemRunPlan- Nutzlast. Das Gateway verwendet diesen Plan als maßgeblichen Kontext für Befehl, cwd und Sitzung, wenn genehmigte system.run-Anfragen weitergeleitet werden:

• Der Node-Ausführungspfad bereitet zu Beginn einen kanonischen Plan vor.
• Der Genehmigungsdatensatz speichert diesen Plan und seine Bindungsmetadaten.
• Nach der Genehmigung verwendet der endgültige weitergeleitete system.run-Aufruf den gespeicherten Plan erneut, statt späteren Änderungen des Aufrufers zu vertrauen.
• Wenn der Aufrufer command, rawCommand, cwd, agentId oder sessionKey nach der Erstellung der Genehmigungsanfrage ändert, lehnt das Gateway die weitergeleitete Ausführung wegen einer Abweichung von der Genehmigung ab.

Systemereignisse und Ablehnungen

Der Ausführungslebenszyklus sendet eine Exec finished-Systemnachricht an die Sitzung des Agenten, nachdem der Node den Abschluss meldet. OpenClaw kann außerdem eine Meldung über die laufende Ausführung ausgeben, sobald eine Genehmigung erteilt wurde und tools.exec.approvalRunningNoticeMs verstrichen ist (Standardwert 10000; 0 deaktiviert dies). Abgelehnte Ausführungsgenehmigungen sind für den Host-Befehl endgültig: Der Befehl wird nicht ausgeführt.

• Bei asynchronen Genehmigungen des Hauptagenten mit einer Ursprungssitzung sendet OpenClaw die Ablehnung als interne Folgenachricht zurück in diese Sitzung, damit der Agent nicht weiter auf den asynchronen Befehl wartet und keine Reparatur wegen eines fehlenden Ergebnisses auslöst.
• Wenn keine Sitzung vorhanden ist oder die Sitzung nicht fortgesetzt werden kann, kann OpenClaw dem Betreiber oder dem direkten Chat-Pfad dennoch eine knappe Ablehnung melden.
• Ablehnungen für Subagenten- und Cron-Sitzungen werden nicht zurück in diese Sitzung gesendet.

Ausführungsgenehmigungen des Gateway-Hosts geben dasselbe Abschlussereignis des Lebenszyklus aus. Genehmigungspflichtige Ausführungen verwenden die Genehmigungs-ID erneut, um die ausstehende Anfrage mit ihrer Abschluss- oder Ablehnungsnachricht zu korrelieren (Exec finished (gateway id=...) / Exec denied (gateway id=...)).

Auswirkungen

• full ist leistungsstark; bevorzugen Sie nach Möglichkeit Positivlisten.
• ask bindet Sie weiterhin ein und ermöglicht zugleich schnelle Genehmigungen.
• Agentenspezifische Positivlisten verhindern, dass Genehmigungen eines Agenten auf andere übergreifen.
• Genehmigungen gelten nur für Host-Ausführungsanfragen von autorisierten Absendern. Nicht autorisierte Absender können /exec nicht ausführen.
• /exec security=full ist eine sitzungsbezogene Komfortfunktion für autorisierte Betreiber und überspringt Genehmigungen absichtlich. Um Host-Ausführungen vollständig zu blockieren, setzen Sie die Genehmigungssicherheit auf deny oder verweigern Sie das Werkzeug exec über die Werkzeugrichtlinie.

Verwandte Themen