Summary

In 2026.2.25, commands that are explicitly in the exec-approvals allowlist still trigger approval prompts when their arguments contain shell-like characters (backticks, $, backslashes, etc.).

Steps to reproduce

1. Set tools.exec.security=allowlist with ask=on-miss
2. Add /opt/homebrew/bin/gh to the allowlist (via Always Allow or exec-approvals.json)
3. Run a simple command: /opt/homebrew/bin/gh issue view 26044 --repo openclaw/openclaw → passes without approval ✅
4. Run a command with complex body: /opt/homebrew/bin/gh issue comment 26044 --repo openclaw/openclaw --body "Some text with \backticks` and $variables"` → triggers approval prompt ❌

Expected behavior

Once a binary path is explicitly allowlisted, it should be trusted regardless of argument content. The user has already made the trust decision by adding it to the allowlist.

Actual behavior

Allowlisted commands are re-evaluated based on argument content, triggering unexpected approval prompts for complex but legitimate arguments.

Impact

This undermines trust in the allowlist system. Users expect to build up a library of approved commands and not worry about them later. Unpredictable approval prompts for already-approved binaries create a "cry wolf" effect where users stop carefully reviewing approvals.

Suggestion

• Allowlisted binaries (explicit path match in exec-approvals.json) should bypass argument inspection
• Or at minimum, argument-based flags should be a separate, opt-in layer (e.g. strictArgCheck: true)
• The existing obfuscation detection for interpreters (python3 -c, perl -e) is reasonable — but extending it to all binaries seems overly broad

Environment

• OpenClaw 2026.2.25
• macOS 15.7.4 (arm64)
• Companion app: KatClaw (native macOS frontend)