#Help with approvals

1 messages · Page 1 of 1 (latest)

rancid sail
#

"Windows node host returns SYSTEM_RUN_DENIED on every system.run call. exec-approvals.json is set to security=full, ask=off, askFallback=full with no socket. Node is paired and connected (green on dashboard). Running OpenClaw 2026.3.2 on Windows 11."

Help :((

sudden zephyrBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

rancid sail
#

Wait it didn’t solve

dusk pebbleBOT
#

SYSTEM_RUN_DENIED always comes from the node host’s local exec-approval policy (not from pairing). On Windows this is almost always one of these two situations:

  1. the node host is not actually reading the exec-approvals file you edited (wrong location / wrong user / invalid JSON), so it falls back to tools.exec.security (often allowlist) and denies, or
  2. you’re hitting the Windows-specific rule where cmd.exe /c … wrapper runs get treated as blocked in allowlist mode unless they go through the ask/approval flow.

A couple quick checks to pinpoint which one:

1) Paste the full error string

It matters whether it’s:

  • SYSTEM_RUN_DENIED: approval required
  • SYSTEM_RUN_DENIED: allowlist miss (Windows shell wrappers like cmd.exe /c require approval…)
  • or something else

2) Verify what the gateway thinks the node’s approvals are

From the gateway host, run:

# 
openclaw nodes status
openclaw approvals get --node <id|name|ip>

If that output does not show security: full (or shows allowlist/deny), then your file isn’t being applied.

3) The approvals file must be strict JSON and include version: 1

On the Windows machine running the node host, the file is:

%USERPROFILE%\.openclaw\exec-approvals.json

It is parsed with JSON.parse (no JSON5): no comments, no trailing commas. If parsing fails or version is missing/wrong, it silently falls back.

A minimal known-good file for “just make it run” debugging is:

# 
{
  "version": 1,
  "defaults": {
    "security": "full",
    "ask": "off",
    "askFallback": "full"
  },
  "agents": {}
}

Then apply it via CLI (recommended because it proves the node can read/write approvals):

openclaw approvals set --node <id|name|ip> --file ./exec-approvals.json
# 
openclaw approvals get --node <id|name|ip>

4) If you want allowlist mode on Windows, don’t use ask: off

In allowlist mode, cmd.exe /c ... wrapper runs require approval (by design). Fix is:

  • ask: "on-miss" (or "always") and approve via Control UI, or
  • avoid wrapper forms and run a stable executable argv directly.

Docs that cover this exact Windows behavior:

If you paste:

  1. openclaw --version from the Windows node host machine, and
  2. openclaw approvals get --node … output, and
  3. the exact SYSTEM_RUN_DENIED: ... message,
#

I can tell you which of the above you’re hitting and what to change.

#

Then we’re missing the one piece of info that determines the next step: what exact SYSTEM_RUN_DENIED: … variant are you getting, and what does the gateway/node report as the effective approvals policy.

Can you paste all three of these (as text, not screenshots)?

A) Exact error text (verbatim)

When it fails, does it say:

  • SYSTEM_RUN_DENIED: allowlist miss ... (Windows shell wrappers like cmd.exe /c require approval ...)
  • SYSTEM_RUN_DENIED: approval required
  • SYSTEM_RUN_DISABLED: security=deny
  • something like execution plan mismatch / cwd ...?

Those mean totally different causes.

B) What approvals the node is actually using

Run from the gateway host:

# 
openclaw nodes status
openclaw approvals get --node <id|name|ip>

If this shows anything other than security: full then your edited file is not being applied (wrong file / wrong user / invalid JSON / node host running in a different environment).

C) What the node host itself sees locally (this catches WSL vs native Windows)

On the Windows machine running the node host, run:

openclaw --version
openclaw approvals get

and paste the output.