exec-approvals on a Windows node host | Friends of the Crustacean 🦞🤝 | Page 1

maiden delta Apr 24, 2026, 10:58 AM

#

Setting up exec-approvals on a Windows node host (paired via nodes pair, running as a Scheduled Task, profile nodehost).
Two questions:

Where does the exec-approvals config live for the node host side — is it in the nodehost config directory, or is it pushed from the gateway?
What's the exact format for allowlisting specific binary paths (full resolved paths like C:\Program Files\Git\cmd\git.exe)?

Running v2026.4.20 on both gateway and node. Thanks!

quiet mantleBOT Apr 24, 2026, 10:58 AM

#

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

sly arrowBOT Apr 24, 2026, 10:58 AM

#

silent fractalBOT Apr 24, 2026, 11:01 AM

#

Two layers here:

Gateway requested policy: tools.exec.* in the gateway config
Node-local approvals state: on the node host itself in ~/.openclaw/exec-approvals.json

So for a Windows node host, the file lives on the machine running the Scheduled Task, effectively:

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

It is not stored in the pairing record and not continuously “pushed from the gateway”. The gateway can edit/read that node-local file remotely via:

openclaw approvals get --node <id>
openclaw approvals set --node <id> ...
openclaw approvals allowlist add --node <id> ...

#

For allowlisting binaries, yes, use the full resolved executable path, not just git.exe. Basename-only entries are ignored.

Minimal shape:

{
  "version": 1,
  "agents": {
    "*": {
      "allowlist": [
        { "pattern": "C:\\Program Files\\Git\\cmd\\git.exe" }
      ]
    }
  }
}

#

Notes:

agents."*" = wildcard, all agents
agents.main = just the main agent
patterns are case-insensitive glob matches on Windows
full path is the right approach, for example C:\\Program Files\\Git\\cmd\\git.exe

CLI example:

openclaw approvals allowlist add --node <id> --agent "*" "C:\\Program Files\\Git\\cmd\\git.exe"

One important Windows gotcha: in allowlist mode, shell-wrapper forms like cmd.exe /c ... still require approval, even if git.exe itself is allowlisted. So direct executable invocation matches better than wrapper-style shell commands.

Docs:

https://docs.openclaw.ai/tools/exec-approvals

#

If you want, I can paste a known-good Windows exec-approvals.json for git.exe plus pwsh.exe examples.

maiden delta Apr 24, 2026, 11:03 AM

#

yes.. that would be helpful

silent fractalBOT Apr 24, 2026, 11:04 AM

#

Yep, here are two concrete Windows examples.

Recommended, Git only:

openclaw approvals set --node <id-or-name> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "allowlist",
    ask: "on-miss",
    askFallback: "deny",
    autoAllowSkills: false
  },
  agents: {
    "*": {

#

      allowlist: [
        { pattern: "C:\\Program Files\\Git\\cmd\\git.exe" }
      ]
    }
  }
}
EOF

That writes the node host's local approvals file (%USERPROFILE%\\.openclaw\\exec-approvals.json).

If you want it only for the main agent instead of all agents, use main instead of *.

Equivalent helper command:

#

openclaw approvals allowlist add --node <id-or-name> --agent "*" "C:\\Program Files\\Git\\cmd\\git.exe"

Git + PowerShell, but safer to keep prompts always on:

openclaw approvals set --node <id-or-name> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "allowlist",
    ask: "always",
    askFallback: "deny",

#

    autoAllowSkills: false
  },
  agents: {
    "*": {
      allowlist: [
        { pattern: "C:\\Program Files\\Git\\cmd\\git.exe" },
        { pattern: "C:\\Program Files\\PowerShell\\7\\pwsh.exe" }
      ]
    }
  }
}
EOF

I’d be careful with pwsh.exe, because that is basically interpreter-level access. git.exe is narrow, pwsh.exe is broad.

#

A few useful details:

Exact full path is the right format.
On Windows, matching is case-insensitive and supports globs, but I’d start with exact paths.
CLI allowlist add defaults to agent * if you omit --agent.
In allowlist mode, wrapper forms like cmd.exe /c ... still need approval, even if the inner binary is allowlisted.

So this works best:

git status
direct git.exe ...

Less ideal in allowlist mode:

cmd.exe /c git status

Docs:

#

If you want, I can also give you a good argPattern example for constraining pwsh.exe to only -File some-script.ps1 instead of allowing arbitrary PowerShell args.

maiden delta Apr 24, 2026, 11:04 AM

#

yes

silent fractalBOT Apr 24, 2026, 11:05 AM

#

Yep, here’s a good Windows argPattern example.

If you want to allow only this exact PowerShell shape:

pwsh.exe -NoProfile -File C:\ops\sync.ps1

use a node approvals file like this:

openclaw approvals set --node <id-or-name> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "allowlist",

#

    ask: "on-miss",
    askFallback: "deny",
    autoAllowSkills: false
  },
  agents: {
    "*": {
      allowlist: [
        {
          pattern: "C:\\Program Files\\PowerShell\\7\\pwsh.exe",
          argPattern: "^-NoProfile -File C:\\\\ops\\\\sync\\.ps1$"
        }
      ]
    }
  }
}

#

EOF

A few important details:

pattern = full executable path
argPattern = regex over the args only, not including pwsh.exe
On Windows, argPattern matching is supported
Use openclaw approvals set ... or the Control UI for argPattern, not allowlist add

Very important gotcha:

If you also keep a plain path-only entry like
{ pattern: "C:\\Program Files\\PowerShell\\7\\pwsh.exe" }
then that broader entry can still allow arbitrary args.
So if you want it constrained, keep only the argPattern version.

#

If you want to allow one argument after the script, for example:

pwsh.exe -NoProfile -File C:\ops\sync.ps1 full

then:

{
  pattern: "C:\\Program Files\\PowerShell\\7\\pwsh.exe",
  argPattern: "^-NoProfile -File C:\\\\ops\\\\sync\\.ps1 (full|delta)$"
}

Nice bonus: Windows matching normalizes slash style, so C:/ops/sync.ps1 vs C:\\ops\\sync.ps1 is handled pretty well.

#

Docs:

If you want, I can also give you a Git + pwsh combined example with git.exe broad-allowlisted and pwsh.exe tightly constrained. If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

maiden delta Apr 24, 2026, 11:05 AM

#

please share more if you have any more information on this

silent fractalBOT Apr 24, 2026, 11:06 AM

#

Yep, a few more details that are easy to miss:

The node host owns the approvals file locally. It is not a config blob that lives in the gateway pairing record.
For a Scheduled Task, the path is tied to the account running the task, not necessarily your interactive login.
- normal user task: %USERPROFILE%\\.openclaw\\exec-approvals.json
- if you run it as LocalSystem, that usually means the file lands under the system profile, not your user profile

A few related files on the node host:

~/.openclaw/node.json = node id/token/display name/gateway connection
~/.openclaw/exec-approvals.json = exec approvals state

A few policy details:

Effective exec policy is the stricter merge of:
- gateway tools.exec.*
- node-local exec-approvals.json

#

agents["*"] applies to all agents
agents.main applies to the main agent
wildcard and agent-specific allowlists are effectively combined

For matching:

allowlist matches the resolved executable path
on Windows, path matching is case-insensitive
glob patterns are allowed, but I’d strongly recommend exact full paths first
basename-only entries are ignored, so git.exe alone is not enough

Example broad path allowlist:

{
  version: 1,

#

  agents: {
    "*": {
      allowlist: [
        { pattern: "C:\\Program Files\\Git\\cmd\\git.exe" }
      ]
    }
  }
}

Important nuance:

a plain pattern entry only constrains the binary path
it does not constrain arguments
if you need arg restrictions, use argPattern, which is especially relevant on Windows

#

Example constrained PowerShell:

{
  version: 1,
  agents: {
    "*": {
      allowlist: [
        {
          pattern: "C:\\Program Files\\PowerShell\\7\\pwsh.exe",
          argPattern: "^-NoProfile -File C:\\\\ops\\\\sync\\.ps1$"
        }
      ]
    }
  }
}

#

Windows gotchas:

cmd.exe /c ... still needs approval in allowlist mode, even if the inner exe is allowlisted
direct invocation is better than shell-wrapper invocation
node hosts ignore PATH overrides for safety, so if a tool is not in a standard location, set that up in the task/service environment instead of trying to pass PATH in the exec call

Useful commands:

openclaw approvals get --node <id>
openclaw approvals allowlist add --node <id> "C:\\Program Files\\Git\\cmd\\git.exe"
openclaw approvals set --node <id> --stdin

Also, approvals set accepts JSON5, which is handy for these files.

Docs:

#

If you want, I can give you a recommended Windows starter policy for node hosts, like:

Git-only
Git + a single approved PowerShell script
"cautious but usable" general node-host defaults

maiden delta Apr 24, 2026, 11:07 AM

#

yes

silent fractalBOT Apr 24, 2026, 11:08 AM

#

Nice, here are the 3 Windows starter policies I’d recommend for v2026.4.20.

Also one important non-obvious thing first: on Windows node hosts, the safeBins fast path is effectively not the thing to rely on. For Windows, I’d think in terms of explicit path allowlists plus argPattern where needed.

1) Git-only, best first setup

Good when you mainly want repo inspection / simple git ops.

openclaw approvals set --node <id-or-name> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "allowlist",
    ask: "on-miss",
    askFallback: "deny",

#

    autoAllowSkills: false
  },
  agents: {
    "*": {
      allowlist: [
        { pattern: "C:\\Program Files\\Git\\cmd\\git.exe" }
      ]
    }
  }
}
EOF

2) Git + exactly one PowerShell script

Much safer than allowlisting pwsh.exe broadly.

#

openclaw approvals set --node <id-or-name> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "allowlist",
    ask: "on-miss",
    askFallback: "deny",
    autoAllowSkills: false
  },
  agents: {
    "*": {
      allowlist: [
        { pattern: "C:\\Program Files\\Git\\cmd\\git.exe" },
        {
          pattern: "C:\\Program Files\\PowerShell\\7\\pwsh.exe",

#

          argPattern: "^-NoProfile -File C:\\\\ops\\\\sync\\.ps1$"
        }
      ]
    }
  }
}
EOF

That only matches args after pwsh.exe, so it constrains PowerShell to that one script shape.

3) Cautious but usable general default

If you want broader use, I’d still keep prompts always on for interpreters/wrappers.

#

openclaw approvals set --node <id-or-name> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "allowlist",
    ask: "always",
    askFallback: "deny",
    autoAllowSkills: false
  },
  agents: {
    "*": {
      allowlist: [
        { pattern: "C:\\Program Files\\Git\\cmd\\git.exe" },
        { pattern: "C:\\Program Files\\Git\\usr\\bin\\ssh.exe" },
        { pattern: "C:\\Program Files\\Git\\usr\\bin\\scp.exe" }

#

      ]
    }
  }
}
EOF

A few extra tips that matter on Windows:

The approvals file is local to the node host account, usually %USERPROFILE%\\.openclaw\\exec-approvals.json
If the Scheduled Task runs as another account, that account gets its own file
cmd.exe /c ... still needs approval in allowlist mode, even if the inner exe is allowlisted
Direct invocation is better than wrapper invocation
allowlist add is great for plain path entries, but for argPattern use approvals set --stdin or the Control UI
pattern matches the resolved exe path, case-insensitively on Windows. Basename-only entries like git.exe are not enough

#

Useful checks:

openclaw approvals get --node <id-or-name>
openclaw nodes describe --node <id-or-name>

Docs:

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

maiden delta Apr 24, 2026, 10:23 PM

#

What's the correct CLI command to send an exec call from the gateway to a paired node host in v2026.4.20? Trying to run a binary on the node (e.g. git.exe --version) as a smoke test. Is it via openclaw nodes or a different subcommand?

#exec-approvals on a Windows node host

1) Git-only, best first setup

2) Git + exactly one PowerShell script

3) Cautious but usable general default