Naar hoofdinhoud gaan
Exec-goedkeuringen zijn de beveiligingsgrens van de companion-app / Node-host waarmee een gesandboxte agent opdrachten op een echte host (gateway of node) kan uitvoeren. Een veiligheidsvergrendeling: opdrachten zijn alleen toegestaan wanneer beleid + allowlist + (optionele) gebruikersgoedkeuring allemaal overeenstemmen. Exec-goedkeuringen komen boven op toolbeleid en verhoogde gating (tenzij elevated is ingesteld op full, waardoor goedkeuringen worden overgeslagen). Zie voor een modusgerichte uitleg van deny, allowlist, ask, auto, full, Codex Guardian-mapping en ACPX-harnessmachtigingen Permission modes.
Effectief beleid is de strengere van tools.exec.* en de standaardwaarden voor goedkeuringen; als een goedkeuringsveld wordt weggelaten, wordt de waarde van tools.exec gebruikt. Host-exec gebruikt ook lokale goedkeuringsstatus op die machine - een host-lokale ask: "always" in het goedkeuringsbestand van de uitvoeringshost blijft vragen, zelfs als sessie- of configuratiestandaarden ask: "on-miss" aanvragen.

​
Het effectieve beleid inspecteren

OpdrachtWat het toont
openclaw approvals get / --gateway / --node <id|name|ip>Aangevraagd beleid, hostbeleidsbronnen en het effectieve resultaat.
openclaw exec-policy showSamengevoegde weergave van de lokale machine.
openclaw exec-policy set / presetSynchroniseer het lokaal aangevraagde beleid in één stap met het lokale hostgoedkeuringsbestand.
Wanneer een lokaal bereik host=node aanvraagt, rapporteert exec-policy show dat bereik tijdens runtime als door de node beheerd, in plaats van te doen alsof het lokale goedkeuringsbestand de bron van waarheid is. Als de UI van de companion-app niet beschikbaar is, wordt elk verzoek dat normaal om bevestiging zou vragen afgehandeld door de ask-fallback (standaard: deny).
Native chatgoedkeuringsclients kunnen kanaalspecifieke mogelijkheden op het wachtende goedkeuringsbericht voorbereiden. Matrix bereidt bijvoorbeeld reactiesnelkoppelingen voor (✅ één keer toestaan, ❌ weigeren, ♾️ altijd toestaan) terwijl /approve ...-opdrachten in het bericht beschikbaar blijven als fallback.

​
Waar het van toepassing is

Exec-goedkeuringen worden lokaal afgedwongen op de uitvoeringshost:
  • Gateway-host → openclaw-proces op de gateway-machine.
  • Node-host → node-runner (macOS-companion-app of headless Node-host).

​
Vertrouwensmodel

  • Door de Gateway geauthenticeerde aanroepers zijn vertrouwde operators voor die Gateway.
  • Gekoppelde nodes breiden die vertrouwde operatorcapaciteit uit naar de Node-host.
  • Exec-goedkeuringen verminderen het risico op onbedoelde uitvoering, maar zijn geen auth-grens per gebruiker of alleen-lezenbeleid voor het bestandssysteem.
  • Na goedkeuring kan een opdracht bestanden wijzigen volgens de geselecteerde host- of sandboxbestandssysteemmachtigingen.
  • Goedgekeurde Node-hostruns binden canonieke uitvoeringscontext: canonieke cwd, exacte argv, env-binding indien aanwezig, en vastgezette uitvoerbare pad wanneer van toepassing.
  • Voor shellscripts en directe bestandsaanroepen via interpreter/runtime probeert OpenClaw ook één concreet lokaal bestandsoperand te binden. Als dat gebonden bestand na goedkeuring maar vóór uitvoering verandert, wordt de run geweigerd in plaats van gewijzigde inhoud uit te voeren.
  • Bestandsbinding is bewust best-effort, geen volledig semantisch model van elk loaderpad van elke interpreter/runtime. Als de goedkeuringsmodus niet exact één concreet lokaal bestand kan identificeren om te binden, weigert deze een door goedkeuring ondersteunde run te minten in plaats van volledige dekking te veinzen.

​
macOS-splitsing

  • De Node-hostservice stuurt system.run door naar de macOS-app via lokale IPC.
  • De macOS-app dwingt goedkeuringen af en voert de opdracht uit in UI-context.

​
Instellingen en opslag

Goedkeuringen staan in een lokaal JSON-bestand op de uitvoeringshost. Wanneer OPENCLAW_STATE_DIR is ingesteld, volgt het bestand die statusmap; anders gebruikt het de standaard OpenClaw-statusmap: 
$OPENCLAW_STATE_DIR/exec-approvals.json
# otherwise
~/.openclaw/exec-approvals.json
De standaard goedkeuringssocket volgt dezelfde root: $OPENCLAW_STATE_DIR/exec-approvals.sock, of ~/.openclaw/exec-approvals.sock wanneer de variabele niet is ingesteld. Voorbeeldschema: 
{
  "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"
        }
      ]
    }
  }
}

​
Beleidsknoppen

​
tools.exec.mode

tools.exec.mode is het aanbevolen genormaliseerde beleidsoppervlak voor host-exec. Waarden zijn:
  • deny - blokkeer host-exec.
  • allowlist - voer alleen opdrachten op de allowlist uit zonder te vragen.
  • ask - gebruik allowlistbeleid en vraag bij misses.
  • auto - gebruik allowlistbeleid, voer deterministische matches rechtstreeks uit en stuur goedkeuringsmisses via OpenClaw’s native automatische reviewer voordat wordt teruggevallen op een menselijke goedkeuringsroute.
  • full - voer host-exec uit zonder goedkeuringsprompts.
Legacy tools.exec.security / tools.exec.ask blijven ondersteund en hebben nog steeds voorrang wanneer ze op het nauwere sessie- of agentbereik zijn ingesteld.

​
exec.security

​
security
"deny" | "allowlist" | "full"
  • deny - blokkeer alle host-exec-verzoeken.
  • allowlist - sta alleen opdrachten op de allowlist toe.
  • full - sta alles toe (equivalent aan elevated).

​
exec.ask

​
ask
"off" | "on-miss" | "always"
Geconfigureerd ask-beleid voor host-exec. Regelt het basisgedrag van de goedkeuringsprompt vanuit tools.exec.ask en hostgoedkeuringsstandaarden. De per-aanroep ask-toolparameter (zie Exec-tool) kan die basis alleen verstrengen, en modelaanroepen met kanaaloorsprong negeren deze wanneer de effectieve host-ask off is.
  • off - nooit vragen.
  • on-miss - alleen vragen wanneer de allowlist niet overeenkomt.
  • always - bij elke opdracht vragen. Duurzaam vertrouwen met allow-always onderdrukt prompts niet wanneer de effectieve ask-modus always is.

​
askFallback

​
askFallback
"deny" | "allowlist" | "full"
Afhandeling wanneer een prompt vereist is maar geen UI bereikbaar is. Als dit veld wordt weggelaten, gebruikt OpenClaw standaard deny.
  • deny - blokkeer.
  • allowlist - sta alleen toe als de allowlist overeenkomt.
  • full - sta toe.

​
tools.exec.strictInlineEval

​
strictInlineEval
boolean
Wanneer true, behandelt OpenClaw inline code-eval-vormen als alleen met goedkeuring, zelfs als de interpreter-binary zelf op de allowlist staat. Defense-in-depth voor interpreter-loaders die niet netjes naar één stabiel bestandsoperand mappen.
Voorbeelden die de strikte modus opvangt:
  • python -c
  • node -e, node --eval, node -p
  • ruby -e
  • perl -e, perl -E
  • php -r
  • lua -e
  • osascript -e
In strikte modus hebben deze opdrachten nog steeds expliciete goedkeuring nodig, en allow-always bewaart niet automatisch nieuwe allowlist-vermeldingen voor ze.

​
tools.exec.commandHighlighting

​
commandHighlighting
boolean
standaard:"false"
Regelt alleen de presentatie in exec-goedkeuringsprompts. Wanneer ingeschakeld, kan OpenClaw parser-afgeleide opdrachtspans toevoegen zodat webgoedkeuringsprompts opdrachttokens kunnen markeren. Stel dit in op true om markering van opdrachttekst in te schakelen.
Deze instelling wijzigt security, ask, allowlist-matching, strikt inline-eval-gedrag, doorsturen van goedkeuringen of opdrachtuitvoering niet. Deze kan globaal worden ingesteld onder tools.exec.commandHighlighting of per agent onder agents.list[].tools.exec.commandHighlighting.

​
YOLO-modus (geen goedkeuring)

Als je host-exec zonder goedkeuringsprompts wilt laten uitvoeren, moet je beide beleidslagen openen - aangevraagd exec-beleid in de OpenClaw-configuratie (tools.exec.*) en host-lokaal goedkeuringsbeleid in het goedkeuringsbestand van de uitvoeringshost. OpenClaw gebruikt standaard deny voor weggelaten askFallback. Stel host askFallback expliciet in op full wanneer een goedkeuringsprompt zonder UI moet terugvallen op toestaan.
LaagYOLO-instelling
tools.exec.securityfull op gateway/node
tools.exec.askoff
Host askFallbackfull
Belangrijke verschillen:
  • tools.exec.host=auto kiest waar exec draait: sandbox wanneer beschikbaar, anders gateway.
  • YOLO kiest hoe host-exec wordt goedgekeurd: security=full plus ask=off.
  • In YOLO-modus voegt OpenClaw geen aparte heuristische goedkeuringsgate voor opdrachtobfuscatie of script-preflight-afwijslaag toe boven op het geconfigureerde host-exec-beleid.
  • auto maakt gateway-routing geen vrije override vanuit een gesandboxte sessie. Een per-aanroep host=node-verzoek is toegestaan vanuit auto; host=gateway is vanuit auto alleen toegestaan wanneer geen sandboxruntime actief is. Stel voor een stabiele niet-auto-standaard tools.exec.host in of gebruik expliciet /exec host=....
CLI-gestuurde providers die hun eigen niet-interactieve machtigingsmodus aanbieden, kunnen dit beleid volgen. Claude CLI voegt --permission-mode bypassPermissions toe wanneer OpenClaw’s effectieve exec-beleid YOLO is. Voor door OpenClaw beheerde Claude-live-sessies is OpenClaw’s effectieve exec-beleid gezaghebbend boven Claude’s native machtigingsmodus: YOLO normaliseert live-starts naar --permission-mode bypassPermissions, en restrictief effectief exec-beleid normaliseert live-starts naar --permission-mode default, zelfs als ruwe Claude-backendargs een andere modus opgeven. Als je een conservatievere setup wilt, verstreng dan het OpenClaw-exec-beleid terug naar allowlist / on-miss of deny.

​
Permanente gateway-hostsetup met “nooit vragen”

1

Stel het aangevraagde configuratiebeleid in

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

Laat het hostgoedkeuringsbestand overeenkomen

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

​
Lokale snelkoppeling

openclaw exec-policy preset yolo
Die lokale snelkoppeling werkt beide bij:
  • Lokale tools.exec.host/security/ask.
  • Standaardwaarden van het lokale goedkeuringsbestand, inclusief askFallback: "full".
Deze is bewust alleen lokaal. Gebruik openclaw approvals set --gateway of openclaw approvals set --node <id|name|ip> om gateway-host- of Node-hostgoedkeuringen op afstand te wijzigen.

​
Node-host

Pas voor een Node-host hetzelfde goedkeuringsbestand toe op die node: 
openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF
Alleen-lokale beperkingen:
  • openclaw exec-policy synchroniseert geen node-goedkeuringen.
  • openclaw exec-policy set --host node wordt geweigerd.
  • Node-exec-goedkeuringen worden tijdens runtime van de node opgehaald, dus node-gerichte updates moeten openclaw approvals --node ... gebruiken.

​
Snelkoppeling alleen voor sessie

  • /exec security=full ask=off wijzigt alleen de huidige sessie.
  • /elevated full is een noodsnelkoppeling die exec-goedkeuringen alleen overslaat wanneer zowel het aangevraagde beleid als het hostgoedkeuringsbestand uitkomen op security: "full" en ask: "off". Een strenger hostbestand, zoals ask: "always", vraagt nog steeds om bevestiging.
Als het hostgoedkeuringsbestand strenger blijft dan de configuratie, wint het strengere hostbeleid nog steeds.

​
Allowlist (per agent)

Allowlists zijn per agent. Als er meerdere agents bestaan, wissel dan in de macOS-app welke agent je bewerkt. Patronen zijn glob-overeenkomsten. Patronen kunnen opgeloste globs voor binaire paden zijn of kale globs voor opdrachtnamen. Kale namen komen alleen overeen met opdrachten die via PATH worden aangeroepen, dus rg kan overeenkomen met /opt/homebrew/bin/rg wanneer de opdracht rg is, maar niet met ./rg of /tmp/rg. Gebruik een padglob wanneer je één specifieke binaire locatie wilt vertrouwen. Verouderde agents.default-vermeldingen worden bij het laden gemigreerd naar agents.main. Shell-ketens zoals echo ok && pwd moeten nog steeds elk topniveau-segment aan de allowlist-regels laten voldoen. Voorbeelden:
  • rg
  • ~/Projects/**/bin/peekaboo
  • ~/.local/bin/*
  • /opt/homebrew/bin/rg

​
Argumenten beperken met argPattern

Voeg argPattern toe wanneer een allowlist-vermelding moet overeenkomen met een binary en een specifieke argumentvorm. OpenClaw evalueert de reguliere expressie tegen de geparseerde opdrachtargumenten, exclusief het uitvoerbare token (argv[0]). Voor handmatig geschreven vermeldingen worden argumenten samengevoegd met één spatie, dus veranker het patroon wanneer je een exacte overeenkomst nodig hebt. 
{
  "version": 1,
  "agents": {
    "main": {
      "allowlist": [
        {
          "pattern": "python3",
          "argPattern": "^safe\\.py$"
        }
      ]
    }
  }
}
Die vermelding staat python3 safe.py toe; python3 other.py mist de allowlist. Als er ook een alleen-pad-vermelding voor dezelfde binary aanwezig is, kunnen niet-overeenkomende argumenten nog steeds terugvallen op die alleen-pad-vermelding. Laat de alleen-pad- vermelding weg wanneer het doel is om de binary te beperken tot de gedeclareerde argumenten. Vermeldingen die door goedkeuringsflows zijn opgeslagen, kunnen een interne scheidingstekenindeling gebruiken voor exacte argv-overeenkomst. Gebruik bij voorkeur de UI of goedkeuringsflow om die vermeldingen opnieuw te genereren in plaats van de gecodeerde waarde handmatig te bewerken. Als OpenClaw argv voor een opdrachtsegment niet kan parsen, komen vermeldingen met argPattern niet overeen. Elke allowlist-vermelding ondersteunt:
VeldBetekenis
patternOpgeloste glob voor binair pad of kale glob voor opdrachtnaam
argPatternOptionele argv-regex; weggelaten vermeldingen zijn alleen-pad
idStabiele UUID die wordt gebruikt voor UI-identiteit
sourceBron van de vermelding, zoals allow-always
commandTextOpdrachttekst vastgelegd toen een goedkeuringsflow de vermelding maakte
lastUsedAtTijdstempel van laatste gebruik
lastUsedCommandLaatste opdracht die overeenkwam
lastResolvedPathLaatst opgeloste binaire pad

​
Skill-CLI’s automatisch toestaan

Wanneer Skill-CLI’s automatisch toestaan is ingeschakeld, worden uitvoerbare bestanden waarnaar door bekende Skills wordt verwezen behandeld als toegestaan op nodes (macOS-node of headless node-host). Dit gebruikt skills.bins via de Gateway-RPC om de skill-binlijst op te halen. Schakel dit uit als je strikt handmatige allowlists wilt.
  • Dit is een impliciete gemaks-allowlist, los van handmatige pad-allowlistvermeldingen.
  • Het is bedoeld voor vertrouwde operatoromgevingen waar Gateway en node binnen dezelfde vertrouwensgrens vallen.
  • Als je strikt expliciet vertrouwen vereist, houd autoAllowSkills: false en gebruik alleen handmatige pad-allowlistvermeldingen.

​
Veilige bins en goedkeuring doorsturen

Voor veilige bins (het stdin-only snelle pad), details over interpreterbinding en hoe je goedkeuringsprompts doorstuurt naar Slack/Discord/Telegram (of ze uitvoert als native goedkeuringsclients), zie Exec-goedkeuringen - geavanceerd.

​
Bewerken in de Control UI

Gebruik de kaart Control UI → Nodes → Exec approvals om standaardwaarden, per-agent-overschrijvingen en allowlists te bewerken. Kies een scope (Standaardwaarden of een agent), pas het beleid aan, voeg allowlist-patronen toe of verwijder ze, en kies daarna Opslaan. De UI toont metadata over laatste gebruik per patroon, zodat je de lijst netjes kunt houden. De doelselector kiest Gateway (lokale goedkeuringen) of een Node. Nodes moeten system.execApprovals.get/set adverteren (macOS-app of headless node-host). Als een node exec-goedkeuringen nog niet adverteert, bewerk dan rechtstreeks het lokale goedkeuringsbestand. CLI: openclaw approvals ondersteunt bewerken van gateway of node - zie Goedkeurings-CLI.

​
Goedkeuringsflow

Wanneer een prompt vereist is, zendt de gateway exec.approval.requested uit naar operatorclients. De Control UI en macOS- app lossen dit op via exec.approval.resolve, waarna de gateway het goedgekeurde verzoek doorstuurt naar de node-host. Voor host=node bevatten goedkeuringsverzoeken een canonieke systemRunPlan- payload. De gateway gebruikt dat plan als de gezaghebbende opdracht/cwd/sessie-context wanneer goedgekeurde system.run- verzoeken worden doorgestuurd. Dat is belangrijk voor latentie bij asynchrone goedkeuring:
  • Het node-exec-pad bereidt vooraf één canoniek plan voor.
  • Het goedkeuringsrecord slaat dat plan en de bindingsmetadata ervan op.
  • Zodra het is goedgekeurd, hergebruikt de uiteindelijk doorgestuurde system.run-aanroep het opgeslagen plan in plaats van latere bewerkingen door de aanroeper te vertrouwen.
  • Als de aanroeper command, rawCommand, cwd, agentId of sessionKey wijzigt nadat het goedkeuringsverzoek is gemaakt, weigert de gateway de doorgestuurde uitvoering als een goedkeuringsmismatch.

​
Systeemgebeurtenissen

De exec-levenscyclus wordt weergegeven als systeemberichten:
  • Exec running (alleen als de opdracht de drempel voor een lopende melding overschrijdt).
  • Exec finished.
Deze worden in de sessie van de agent geplaatst nadat de node de gebeurtenis rapporteert. Geweigerde exec-goedkeuringen zijn terminaal voor de hostopdracht zelf: de opdracht wordt niet uitgevoerd. Voor asynchrone goedkeuringen van de hoofdagent met een oorspronkelijke sessie plaatst OpenClaw de weigering terug in die sessie als een interne follow-up, zodat de agent kan stoppen met wachten op de asynchrone opdracht en een reparatie voor een ontbrekend resultaat kan vermijden. Als er geen sessie is of de sessie niet kan worden hervat, kan OpenClaw nog steeds een beknopte weigering rapporteren aan de operator of directe chatroute. Weigeringen voor subagentsessies worden niet teruggeplaatst in de subagent. Exec-goedkeuringen op Gateway-host zenden dezelfde levenscyclusgebeurtenissen uit wanneer de opdracht voltooid is (en optioneel wanneer deze langer draait dan de drempel). Execs met goedkeuringspoort hergebruiken de goedkeurings-id als de runId in deze berichten voor eenvoudige correlatie.

​
Gedrag bij geweigerde goedkeuring

Wanneer een asynchrone exec-goedkeuring wordt geweigerd, behandelt OpenClaw de hostopdracht als terminaal en fail-closed. Voor hoofdagentsessies wordt de weigering geleverd als een interne sessie-follow-up die de agent vertelt dat de asynchrone opdracht niet is uitgevoerd. Dat behoudt transcriptcontinuïteit zonder verouderde opdrachtuitvoer bloot te stellen. Als sessielevering niet beschikbaar is, valt OpenClaw terug op een beknopte operator- of directe-chatweigering wanneer er een veilige route bestaat.

​
Implicaties

  • full is krachtig; geef waar mogelijk de voorkeur aan allowlists.
  • ask houdt je betrokken terwijl snelle goedkeuringen nog steeds mogelijk zijn.
  • Per-agent-allowlists voorkomen dat goedkeuringen van één agent naar andere agents lekken.
  • Goedkeuringen zijn alleen van toepassing op host-exec-verzoeken van geautoriseerde afzenders. Ongeautoriseerde afzenders kunnen geen /exec uitvoeren.
  • /exec security=full is een gemak op sessieniveau voor geautoriseerde operators en slaat goedkeuringen bewust over. Stel goedkeuringsbeveiliging in op deny of weiger de exec-tool via toolbeleid om host-exec hard te blokkeren.

​
Gerelateerd

Exec approvals - advanced

Veilige bins, interpreterbinding en goedkeuring doorsturen naar chat.

Exec tool

Tool voor het uitvoeren van shell-opdrachten.

Elevated mode

Noodpad dat ook goedkeuringen overslaat.

Sandboxing

Sandboxmodi en toegang tot werkruimten.

Security

Beveiligingsmodel en hardening.

Sandbox vs tool policy vs elevated

Wanneer je welke controle gebruikt.

Skills

Automatisch toestaan op basis van Skills.