​

Exec-Genehmigungen

​

Wo dies gilt

• Gateway-Host → openclaw-Prozess auf dem Gateway-Rechner
• Node-Host → Node-Runner (macOS-Companion-App oder Headless-Node-Host)

• Für das Gateway authentifizierte Aufrufer sind vertrauenswürdige Operatoren für dieses Gateway.
• Gekoppelte Nodes erweitern diese Fähigkeit als vertrauenswürdiger Operator auf den Node-Host.
• Exec-Genehmigungen verringern das Risiko versehentlicher Ausführung, sind aber keine Authentifizierungsgrenze pro Benutzer.
• Genehmigte Ausführungen auf dem Node-Host binden den kanonischen Ausführungskontext: kanonisches cwd, exaktes argv, env-Bindung falls vorhanden und angehefteten ausführbaren Pfad, sofern zutreffend.
• Für Shell-Skripte und direkte Interpreter-/Runtime-Dateiaufrufe versucht OpenClaw außerdem, genau einen konkreten lokalen Dateiopeanden zu binden. Wenn sich diese gebundene Datei nach der Genehmigung, aber vor der Ausführung ändert, wird die Ausführung verweigert, statt abgewichenen Inhalt auszuführen.
• Diese Dateibindung ist absichtlich Best-Effort und kein vollständiges semantisches Modell jedes Interpreter-/Runtime-Ladepfads. Wenn der Genehmigungsmodus nicht genau eine konkrete lokale Datei zur Bindung identifizieren kann, verweigert er die Erstellung einer genehmigungsgestützten Ausführung, statt vollständige Abdeckung vorzutäuschen.

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

​

Einstellungen und Speicherung

{
  "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"
        }
      ]
    }
  }
}

​

„YOLO“-Modus ohne Genehmigungen

• angeforderte Exec-Richtlinie in der OpenClaw-Konfiguration (tools.exec.*)
• hostlokale Genehmigungsrichtlinie in ~/.openclaw/exec-approvals.json

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

• tools.exec.host=auto wählt aus, wo Exec ausgeführt wird: in der Sandbox, wenn verfügbar, andernfalls auf dem Gateway.
• YOLO wählt aus, wie Host-Exec genehmigt wird: security=full plus ask=off.
• Im YOLO-Modus fügt OpenClaw keine zusätzliche heuristische Genehmigungsschranke für Befehlsverschleierung und keine Skript-Preflight-Ablehnungsebene zusätzlich zur konfigurierten Host-Exec-Richtlinie hinzu.
• auto macht Gateway-Routing nicht zu einer freien Umgehung aus einer Sandbox-Sitzung heraus. Eine Anfrage pro Aufruf mit host=node ist von auto aus erlaubt, und host=gateway ist von auto aus nur erlaubt, wenn keine Sandbox-Runtime aktiv ist. Wenn Sie einen stabilen Nicht-auto-Standard wollen, setzen Sie tools.exec.host oder verwenden Sie /exec host=... explizit.

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

• lokale tools.exec.host/security/ask
• lokale Standardwerte in ~/.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 synchronisiert keine Node-Genehmigungen
• openclaw exec-policy set --host node wird abgelehnt
• Node-Exec-Genehmigungen werden zur Laufzeit vom Node abgerufen, daher müssen zielgerichtete Aktualisierungen für Nodes openclaw approvals --node ... verwenden

• /exec security=full ask=off ändert nur die aktuelle Sitzung.
• /elevated full ist eine Notfall-Kurzform, die für diese Sitzung auch Exec-Genehmigungen überspringt.

​

Richtlinienschalter

​

Sicherheit (exec.security)

• deny: alle Host-Exec-Anfragen blockieren.
• allowlist: nur Befehle aus der Allowlist erlauben.
• full: alles erlauben (entspricht elevated).

​

Ask (exec.ask)

• off: nie nachfragen.
• on-miss: nur nachfragen, wenn die Allowlist nicht passt.
• always: bei jedem Befehl nachfragen.
• Dauerhaftes Vertrauen per allow-always unterdrückt Rückfragen nicht, wenn der wirksame Ask-Modus always ist

​

Ask-Fallback (askFallback)

• deny: blockieren.
• allowlist: nur erlauben, wenn die Allowlist passt.
• full: erlauben.

​

Härtung für Inline-Interpreter-Eval (tools.exec.strictInlineEval)

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

• benötigen diese Befehle weiterhin eine explizite Genehmigung;
• persistiert allow-always dafür nicht automatisch neue Allowlist-Einträge.

​

Allowlist (pro Agent)

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

• id stabile UUID für die UI-Identität (optional)
• last used Zeitstempel
• last used command
• last resolved path

​

Skill-CLIs automatisch erlauben

• Dies ist eine implizite Convenience-Allowlist, getrennt von manuellen Pfad-Allowlist-Einträgen.
• Sie ist für vertrauenswürdige Operatorumgebungen gedacht, in denen Gateway und Node dieselbe Vertrauensgrenze teilen.
• Wenn Sie striktes explizites Vertrauen benötigen, belassen Sie autoAllowSkills: false und verwenden Sie nur manuelle Pfad-Allowlist-Einträge.

​

Sichere Binaries (nur 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

​

Sichere Binaries im Vergleich zur Allowlist

• safeBins kommt aus der Konfiguration (tools.exec.safeBins oder pro Agent agents.list[].tools.exec.safeBins).
• safeBinTrustedDirs kommt aus der Konfiguration (tools.exec.safeBinTrustedDirs oder pro Agent agents.list[].tools.exec.safeBinTrustedDirs).
• safeBinProfiles kommt aus der Konfiguration (tools.exec.safeBinProfiles oder pro Agent agents.list[].tools.exec.safeBinProfiles). Profilschlüssel pro Agent überschreiben globale Schlüssel.
• Allowlist-Einträge liegen in der hostlokalen ~/.openclaw/exec-approvals.json unter agents.<id>.allowlist (oder über die Control UI / openclaw approvals allowlist ...).
• openclaw security audit warnt mit tools.exec.safe_bins_interpreter_unprofiled, wenn Interpreter-/Runtime-Binaries in safeBins ohne explizite Profile erscheinen.
• openclaw doctor --fix kann fehlende benutzerdefinierte safeBinProfiles.<bin>-Einträge als {} vorbereiten (anschließend prüfen und verschärfen). Interpreter-/Runtime-Binaries werden nicht automatisch vorbereitet.

​

Bearbeiten in der Control UI

​

Genehmigungsablauf

• der Node-Exec-Pfad bereitet einen kanonischen Plan im Voraus vor
• der Genehmigungsdatensatz speichert diesen Plan und seine Bindungsmetadaten
• nach der Genehmigung verwendet der endgültig 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 ändert, nachdem die Genehmigungsanfrage erstellt wurde, lehnt das Gateway die weitergeleitete Ausführung als Genehmigungsabweichung ab

​

Interpreter-/Runtime-Befehle

• Exakter argv-/cwd-/env-Kontext wird immer gebunden.
• Direkte Shell-Skript- und direkte Runtime-Dateiformen werden bestmöglich an genau einen konkreten lokalen Dateisnapshot gebunden.
• Häufige Paketmanager-Wrapper-Formen, die sich trotzdem zu genau einer direkten lokalen Datei auflösen (zum Beispiel pnpm exec, pnpm node, npm exec, npx), werden vor der Bindung entpackt.
• Wenn OpenClaw für einen Interpreter-/Runtime-Befehl nicht genau eine konkrete lokale Datei identifizieren kann (zum Beispiel Paketskripte, Eval-Formen, Runtime-spezifische Loader-Ketten oder mehrdeutige Mehrdatei- Formen), wird die genehmigungsgestützte Ausführung abgelehnt, statt semantische Abdeckung zu behaupten, die sie nicht hat.
• Für solche Workflows bevorzugen Sie Sandboxing, eine separate Host-Grenze oder einen explizit vertrauenswürdigen Allowlist-/Full-Workflow, bei dem der Operator die weitergehende Runtime-Semantik akzeptiert.

​

Verhalten bei Follow-up-Zustellung

• Wenn ein gültiges externes Zustellungsziel existiert (zustellbarer Channel plus Ziel to), verwendet die Follow-up-Zustellung diesen Channel.
• In reinen Webchat- oder internen Sitzungsabläufen ohne externes Ziel bleibt die Follow-up-Zustellung sitzungsintern (deliver: false).
• Wenn ein Aufrufer explizit strikte externe Zustellung anfordert, aber kein externer Channel aufgelöst werden kann, schlägt die Anfrage mit INVALID_REQUEST fehl.
• Wenn bestEffortDeliver aktiviert ist und kein externer Channel aufgelöst werden kann, wird die Zustellung auf sitzungsintern herabgestuft, statt fehlzuschlagen.

• Befehl + Argumente
• cwd
• Agent-ID
• aufgelösten Pfad der ausführbaren Datei
• Host- + Richtlinienmetadaten

• Allow once → jetzt ausführen
• Always allow → zur Allowlist hinzufügen + ausführen
• Deny → blockieren

​

Genehmigungsweiterleitung an Chat-Channels

​

Weiterleitung von Plugin-Genehmigungen

​

Genehmigungen im selben Chat auf jedem Channel

​

Native Genehmigungszustellung

• die Host-Exec-Richtlinie entscheidet weiterhin, ob eine Exec-Genehmigung erforderlich ist
• approvals.exec steuert die Weiterleitung von Genehmigungsabfragen an andere Chat-Ziele
• channels.<channel>.execApprovals steuert, ob dieser Channel als nativer Genehmigungsclient fungiert

• der Channel unterstützt native Genehmigungszustellung
• Genehmigende können aus expliziten execApprovals.approvers oder den dokumentierten Fallback-Quellen dieses Channels aufgelöst werden
• channels.<channel>.execApprovals.enabled ist nicht gesetzt oder "auto"

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

• Slack, Matrix, Microsoft Teams und ähnliche zustellbare Chats verwenden das normale Channel-Auth-Modell für /approve im selben Chat
• wenn ein nativer Genehmigungsclient automatisch aktiviert wird, ist das standardmäßige native Zustellungsziel DMs für Genehmigende
• bei Discord und Telegram können nur aufgelöste Genehmigende genehmigen oder ablehnen
• Discord-Genehmigende können explizit sein (execApprovals.approvers) oder aus commands.ownerAllowFrom abgeleitet werden
• Telegram-Genehmigende können explizit sein (execApprovals.approvers) oder aus vorhandener Owner-Konfiguration abgeleitet werden (allowFrom, plus defaultTo für Direktnachrichten, wo unterstützt)
• Slack-Genehmigende können explizit sein (execApprovals.approvers) oder aus commands.ownerAllowFrom abgeleitet werden
• native Slack-Buttons bewahren die Art der Genehmigungs-ID, sodass plugin:-IDs Plugin-Genehmigungen ohne eine zweite Slack-lokale Fallback-Ebene auflösen können
• natives Matrix-DM-/Channel-Routing und Reaktionskürzel verarbeiten sowohl Exec- als auch Plugin-Genehmigungen; die Plugin-Autorisierung kommt weiterhin aus channels.matrix.dm.allowFrom
• der Anfragende muss kein Genehmigender sein
• der Ursprungs-Chat kann direkt mit /approve genehmigen, wenn dieser Chat bereits Befehle und Antworten unterstützt
• native Discord-Genehmigungsbuttons routen nach Art der Genehmigungs-ID: plugin:-IDs gehen direkt zu Plugin-Genehmigungen, alles andere geht zu Exec-Genehmigungen
• native Telegram-Genehmigungsbuttons folgen demselben begrenzten Exec-zu-Plugin-Fallback wie /approve
• wenn natives target die Zustellung an den Ursprungs-Chat aktiviert, enthalten Genehmigungsabfragen den Befehlstext
• ausstehende Exec-Genehmigungen laufen standardmäßig nach 30 Minuten ab
• wenn keine Operator-UI oder kein konfigurierter Genehmigungsclient die Anfrage annehmen kann, fällt die Abfrage auf askFallback zurück

• Discord
• Telegram

​

macOS-IPC-Ablauf

• Unix-Socket-Modus 0600, Token gespeichert in exec-approvals.json.
• Same-UID-Peer-Prüfung.
• Challenge/Response (Nonce + HMAC-Token + Request-Hash) + kurze TTL.

​

Systemereignisse

• Exec running (nur wenn der Befehl den Schwellenwert für die Laufmeldung überschreitet)
• Exec finished
• Exec denied

​

Verhalten bei abgelehnter Genehmigung

​

Auswirkungen

• full ist mächtig; bevorzugen Sie wenn möglich Allowlists.
• ask hält Sie im Ablauf, ermöglicht aber weiterhin schnelle Genehmigungen.
• Allowlists pro Agent verhindern, dass die Genehmigungen eines Agenten in andere übergreifen.
• Genehmigungen gelten nur für Host-Exec-Anfragen von autorisierten Sendern. Nicht autorisierte Sender können /exec nicht ausführen.
• /exec security=full ist eine Sitzungs-Kurzform für autorisierte Operatoren und überspringt Genehmigungen absichtlich. Um Host-Exec vollständig zu blockieren, setzen Sie die Genehmigungssicherheit auf deny oder verweigern Sie das Tool exec über die Tool-Richtlinie.

• Exec-Tool
• Elevated-Modus
• Skills

​

Verwandt

• Exec — Tool zur Ausführung von Shell-Befehlen
• Sandboxing — Sandbox-Modi und Workspace-Zugriff
• Sicherheit — Sicherheitsmodell und Härtung
• Sandbox vs Tool-Richtlinie vs Elevated — wann was verwendet werden sollte