How to Use OpenClaw Exec Approvals on Mac

Exec approvals are the difference between a helpful Mac node and an accidental remote shell. In the macOS app, system.run is controlled by Exec approvals, with local policy stored on the Mac. That is exactly where it belongs: the machine executing the command owns the final allow/ask decision.

When this is the right move

Use macOS exec approvals when the assistant needs system.run through the Mac app or node host service. Examples include harmless diagnostics, UI-adjacent scripts, or local automation that genuinely belongs on the Mac. Do not open broad shell access just because approving one command feels annoying.

The practical workflow

1. Open the macOS app settings and review Exec approvals before the first serious system.run task.
2. Start in deny or allowlist mode with ask on miss. That keeps the agent productive for known-safe commands while surfacing surprises.
3. Allowlist resolved binary paths or bare command names carefully. Prefer exact tools over broad shells.
4. Treat shell wrappers and pipelines as high risk. The docs say control syntax like &&, pipes, redirects, command substitution, and variable expansion triggers allowlist misses.
5. Review the approvals file periodically, especially after choosing Always Allow in prompts.

Grounded command or config pattern

The macOS docs show this local policy shape for exec approvals.

{
  "version": 1,
  "defaults": {
    "security": "deny",
    "ask": "on-miss"
  },
  "agents": {
    "main": {
      "security": "allowlist",
      "ask": "on-miss",
      "allowlist": [{ "pattern": "/opt/homebrew/bin/rg" }]
    }
  }
}

The docs also note that choosing Always Allow in a prompt adds that command to the allowlist. For known dispatch wrappers such as env, nice, nohup, stdbuf, and timeout, OpenClaw may persist inner executable paths when safe; otherwise it avoids adding an unsafe allowlist entry automatically.

Operator notes

Environment handling is intentionally conservative. system.run drops PATH, DYLD_*, LD_*, NODE_OPTIONS, PYTHON*, PERL*, RUBYOPT, SHELLOPTS, PS4, and similar risky overrides before merging with the app environment. For shell wrappers, request-scoped environment overrides are reduced to a small explicit allowlist.

Rollout approach

For use openclaw exec approvals on mac, I would make the first pass deliberately small: one owner, one machine or channel, one visible test, and one rollback path. OpenClaw features become powerful when they connect to real tools and real messages, so the safest rollout is not a giant configuration day. It is a short rehearsal that proves the docs-grounded path works in your exact workspace before you depend on it while busy.

Common mistake

The common mistake is treating the command as the whole feature. The command starts the workflow, but the surrounding state is what keeps it reliable: config validation, auth, pairing, permissions, logs, and a tiny verification step. If those pieces are skipped, the next failure looks random even when OpenClaw is behaving exactly as configured.

Maintenance rhythm

Once this is working, write down the exact command, config path, or approval decision you used. Future you will not remember the tiny detail that made the setup safe. A small note in the workspace or runbook is cheaper than rediscovering the same behavior during an outage, especially after updates or machine changes.

Safety checks

Do not allowlist bash, zsh, or sh broadly unless that is truly your intended trust boundary. A shell can do far more than one binary. If the agent needs a repeatable workflow, wrap the safe operation in a narrow script, review that script, and allowlist the script path rather than arbitrary shell text.

How to verify it worked

Test one allowed command and one disallowed command. The allowed command should run without surprise; the disallowed one should ask or deny based on policy. Then inspect ~/.openclaw/exec-approvals.json to make sure no broad entry was added by accident.

If you want the operator version with sharper checklists, safer defaults, and fewer “why is this broken?” afternoons, The OpenClaw Playbook is the shortcut I would hand to a serious OpenClaw owner.