Feature Request: auto_approve_scope: readonly for healthcheck/canary skills

Problem

Canary/healthcheck/status-check skills are designed to run automatically to detect anomalies. But every introspection command they run hits the exec approvals gate per-invocation, requiring user approval.

Two compounding issues observed (OpenClaw 2026.4.24 on WSL2):

1. No skill-level scope marker for readonly intent. Even a well-spec'd canary skill that only reads config/state must approve each command individually. There is no way to declare "this entire skill operates in read-only mode" at the skill manifest level.

2. Exec-approvals allowlist is exact-hash + path/argPattern. The ~/.openclaw/exec-approvals.json schema accepts:

   • =command:HASH (exact compound-command hash — unstable across runs when the agent slightly varies command strings)
   • pattern: <executable-path> + optional argPattern: <regex> (per-binary)

   Neither expresses "any read-only openclaw {cron list, health, status, gateway status, skills check} invocation by skill X is auto-approved." Users end up with 30+ accumulated =command:HASH entries from allow-always clicks, which still miss the next invocation if the command string varies.

Real-world impact (2026-04-28)

A single canary check round took 20 minutes wall-clock because it triggered 3 separate Telegram approval prompts:

06:05  Approval required → openclaw skills check
06:24  ✅ Exec approval allowed always
06:25  Approval required → openclaw cron list && cron runs && gateway status && health --json && status --deep
06:25  ✅ Exec approval allowed always
06:26  Approval required → (same chain minus `cron runs --id` which was missing arg)
06:26  ✅ Exec approval allowed always
06:28  Canary results delivered (with findings)

Each prompt had a slightly different command-hash, so prior allow-always decisions did not satisfy the next prompt. The user is being trained into rubber-stamping allow-always for any read-only-looking command — eroding the security value of the gate itself.

Proposed solution

Add a metadata.openclaw.execScope field to SKILL.md frontmatter:

metadata:
  openclaw:
    execScope: readonly        # or: mutating | mixed (default: mixed)
    readonlyAllowlist:         # optional, only meaningful when execScope=readonly
      - "openclaw cron list"
      - "openclaw cron list --json"
      - "openclaw health --json"
      - "openclaw status"
      - "openclaw status --deep"
      - "openclaw gateway status"
      - "openclaw skills check"

Runtime behavior:

• When execScope=readonly: any command in readonlyAllowlist auto-approves; any command not in the list still goes through normal approval (preserves boundary)
• When execScope=mixed (default, current behavior): no change
• The list must be prefix or argv-pattern based, not hash-based, so trivial command-string variation doesn't break it
• A fail-closed safeguard: outbound channels (telegram/email/webhook), filesystem writes, service restart, cron mutations are always subject to approval regardless of execScope declaration

Why this is not just auto-approve everything readonly

• The skill author declares intent (readonly) — explicit opt-in, not implicit
• The allowlist is bounded per-skill — cat /etc/shadow doesn't auto-approve just because someone wrote execScope: readonly
• message send / outbound side-effects remain gated even if listed (hard-coded outbound denylist takes precedence)

Reference incident memo

User-side memo: feedback_canary_readonly_auto_approve.md — discusses two parallel root causes:

• (A) Agent freelancing introspection commands beyond SKILL.md spec — fixable in skill (already patched locally)
• (B) Approval gate has no readonly scope concept — requires this upstream change

This issue covers (B) only.

Alternatives considered

1. Hardcode allowlist of openclaw {cron list, health, status, ...} system-wide — rejected: too coarse, doesn't compose with third-party skills
2. Just stop running these commands in canary — works partially (file Read for jobs.json) but openclaw status --deep exposes data not in any single file (gateway state, channel reachability)
3. Per-user allowlist patterns — already exists (agents["*"].allowlist) but pattern format is undocumented and exact-match-leaning

Environment

• OpenClaw: 2026.4.24 (npm 2026.4.25 update available, not yet applied)
• Platform: WSL2 Ubuntu, Node 22.22.0
• Skill: built-in canary-check (workspace skill)