openclaw - 💡(How to fix) Fix Feature: execDenyPathPatterns — config-level denylist for file paths in exec commands [1 comments, 2 participants]

Problem

OpenClaw exec policy has safeBins (allowlist of binaries) but no path-pattern denylist. This means an agent can run cat /home/user/.openclaw/secrets/foo.env and the plaintext token lands in:

1. The session JSONL transcript (on disk, persistent)
2. The next outbound LLM API request body (provider sees it)
3. Any downstream cache, log, or sub-agent fork

Once a secret value crosses into LLM context it must be treated as compromised — full revoke + reissue.

This happened on a production OpenClaw install on 2026-04-29: a sub-agent ran cat ~/.openclaw/secrets/telegram-trader.env to inspect bot config and leaked two Telegram bot tokens. Containment required scrubbing 5 session files and rotating both tokens via BotFather.

Current defenses (insufficient)

• Filesystem perms (chmod 600) — agent runtime runs as the same user; perms don't help.
• Instruction-layer rule (e.g. "never cat secrets/") — LLM may follow it, may not, especially under pressure or in sub-agents that don't inherit the rule.
• safeBins — cat is and should remain in safeBins; restricting it would break everything.

The missing layer is runtime-enforced path denylist that blocks the command before exec, regardless of which binary is invoked.

Proposed config

{
  "tools": {
    "exec": {
      "denyPathPatterns": [
        "~/.openclaw/secrets/**",
        "~/.ssh/id_*",
        "**/.env",
        "**/credentials.json"
      ],
      "denyPathAction": "block"  // or "warn" | "require_approval"
    }
  }
}

Behavior: any exec command whose tokenized arguments resolve to a path matching one of these globs is rejected at the policy layer (same gate as safeBins/approval), with a clear error: exec_blocked: argument matches denyPathPatterns.

Detection scope (v1)

Match against literal path-like arguments after shell-quote unescaping. Don't try to defeat:

• Heredocs, eval'd indirection, base64-decoded paths, `` substitution
• Symlinks pointing at protected paths (out of scope; document)

Goal: catch the 90% lazy-cat case that caused this incident, not build a perfect sandbox.

Why this matters

Every OpenClaw user with a secrets directory has the same vulnerability today. Fix is small (~50 LOC), surface is config-only, default off. Agents that need to ship secrets via env-var loaders aren't affected.

Happy to draft the PR if a maintainer agrees on the config shape.

Reported from: production VPS install, OpenClaw 2026.4.22 / agent runtime, incident write-up in agent's .learnings/ERRORS.md (not public, summary above).