openclaw - 💡(How to fix) Fix exec-approvals defaults override explicit agents.main policy

Summary

exec-approvals.json defaults appear to override or constrain an explicit agents.main policy.

I want restrictive defaults for unknown/other agents, but an explicit permissive policy for the main agent. Despite this, commands run from the main session still trigger approval popups with the values from defaults:

Security: allowlist
Ask: on-miss
Agent: main
Session: agent:main:main

This means defaults behave like a global floor/constraint instead of a fallback, or agents.main is ignored in the effective policy.

Config

~/.openclaw/exec-approvals.json contains restrictive defaults and an explicit main override:

{
  "defaults": {
    "security": "allowlist",
    "ask": "on-miss",
    "askFallback": "deny"
  },
  "agents": {
    "main": {
      "security": "full",
      "ask": "off"
    }
  }
}

The intended meaning is:

• unknown/other agents: restrictive default policy,
• main: explicitly allowed to use full / off,
• user should not have to enumerate every possible agent just to make defaults safe.

Actual behavior

Even in the main session, approval popups are shown for ordinary commands, for example:

true
openclaw status
openclaw status || true
rg -n "exec-approvals|askFallback" ~/.openclaw/workspace ~/.openclaw/exec-approvals.json 2>/dev/null | grep -E "exec|ask|allow" | head -n 40

The approval popup shows the command as coming from:

Agent: main
Session: agent:main:main
Security: allowlist
Ask: on-miss

So the runtime appears to use the restrictive defaults policy for main, despite the explicit agents.main override.

Restarting the gateway did not make agents.main win; the prompts still appeared for the three test commands above.

Expected behavior

For Agent: main, the effective policy should use the explicit agent override:

Security: full
Ask: off

defaults should be used only when there is no matching agent entry.

If the intended semantics are instead "defaults are a global restrictive floor", then the name/shape is misleading and there should be a separate way to express fallback defaults without blocking explicit per-agent overrides.

Real behavior proof / reproduction proof

This is not based on a skill-specific command. It happens for generic commands too.

Environment observed in approval popup:

Host: gateway
Agent: main
Session: agent:main:main
CWD: ~/.openclaw/workspace
Security: allowlist
Ask: on-miss

Commands that triggered the popup from the main session:

openclaw status
openclaw status || true
rg -n "exec-approvals|askFallback|Security: allowlist|autoAllowSkills" ~/.openclaw/workspace ~/.openclaw/exec-approvals.json 2>/dev/null | grep -E "exec|ask|allow|Security" | head -n 40

The popup values matched defaults, not agents.main.

Why this matters

A common safe setup is:

• keep defaults restrictive for unknown/scheduled/subagent contexts,
• explicitly allow the trusted main agent to run without approval prompts.

With the current behavior, users either get approval prompts for every normal main-session command, or they must make defaults permissive, which weakens the fallback posture for everything else.

Related issues / likely same bug family

These look related but do not capture this exact defaults vs explicit agents.main precedence problem:

• #29172
• #58881
• #16348

Requested fix

Please make effective exec approval resolution treat defaults as fallback defaults, not as a global restrictive floor, and ensure an explicit agents.main policy is honored for Agent: main.

A regression test should cover:

1. defaults.security = allowlist, defaults.ask = on-miss
2. agents.main.security = full, agents.main.ask = off
3. effective policy for agentId = "main" resolves to full/off
4. effective policy for an unknown agent resolves to allowlist/on-miss