OpenClaw exec Allowlist Still Can’t Limit Node/Python to One Script: Why Argument-Level Matching Matters

A new OpenClaw feature request points to a practical least-privilege problem in exec policy: today, allowlist rules can match the binary path, but not the arguments passed to that binary.

Source issue: openclaw/openclaw#60427

That sounds subtle, but for real operators it creates a hard choice:

• either deny exec completely
• or allow an interpreter like node or python
• which effectively unlocks arbitrary script execution, not just one trusted script

The real-world problem

The issue describes a common scenario: a restricted agent should be allowed to run one specific moderation script, but should not gain permission to execute any other Node.js program.

With the current model, an allowlist entry can target the binary itself, such as:

• /opt/homebrew/bin/node

But it cannot also say:

• only when node is used with mute_user.mjs <chat_id> <user_id>

That missing middle layer matters because interpreters are broad capability launchers. If you allow the interpreter, you often allow far more than you intended.

Why this is a security design gap, not just a convenience request

This is really about least privilege.

Restricted agents are often used in places like:

• group chat moderation
• low-trust shared channels
• automation that should perform one narrow maintenance action

In those cases, operators do not want a policy that says “run any Node.js code you want.” They want a policy that says “run this exact trusted script, with this expected shape of arguments.”

Without argument-level matching, OpenClaw currently pushes operators toward three imperfect options:

1. Disable exec entirely
   • safest, but kills useful automation
2. Allowlist the interpreter binary
   • restores automation, but expands the blast radius too much
3. Wrap the script in another binary or service
   • workable, but adds packaging, deployment, and audit overhead

What the proposed fix would add

The feature request suggests extending allowlist entries with an optional argument pattern, for example an argsPattern field matched against the command arguments.

In plain language, the rule would become:

• binary path must match
• argument pattern must also match

That would let operators approve something like:

• node /Users/me/.openclaw/mute_user.mjs * *

without approving:

• node arbitrary-other-script.mjs
• node -e "..."
• any other unrelated Node.js execution path

Why this matters operationally

If OpenClaw adds argument-level matching, it would make restricted agents much more usable in production-like environments.

It would especially help teams that want:

• narrow automation in group chats
• safer moderation actions
• cleaner security review for delegated scripts
• better auditability than ad-hoc wrappers

Today, the safest operators often end up building extra glue just to simulate something the policy layer should ideally express directly.

What you can do right now

Until OpenClaw supports argument-aware allowlist rules, the safer workaround is to avoid allowlisting a general-purpose interpreter unless you are comfortable granting that wider power.

More practical stopgaps:

1) Wrap the action in a dedicated executable entry point

If possible, expose the trusted action through a single-purpose wrapper instead of the raw interpreter command.

That makes binary-path allowlisting more precise, even if it adds maintenance cost.

2) Prefer an internal tool or API boundary for sensitive actions

If the workflow is security-sensitive, putting it behind a narrow internal endpoint or dedicated tool can be easier to reason about than granting broad interpreter access.

3) Re-check which agents actually need exec

In low-trust contexts, it may be better to keep exec unavailable and route the action through a higher-trust agent or service instead of widening the allowlist.

Bottom line

This feature request is not asking for “more power.” It is asking for more precise power.

That distinction matters. The current binary-only allowlist model can force operators to choose between no automation and too much automation. Argument-level matching would create the missing middle: approve one trusted script invocation without approving the whole interpreter.

Source

• Feature request: openclaw/openclaw#60427