openclaw - 💡(How to fix) Fix Bug: WebChat/Control UI exec remains denied with allowlist miss even after elevated and provider tool policy are configured [1 comments, 1 participants]

Summary

In WebChat / Control UI, exec remains unavailable with:

exec denied: allowlist miss

even after configuring both:

1. elevated sender allow rules for the WebChat sender identity
2. provider-level tool policy allowing exec and process for webchat

This suggests WebChat / Control UI exec may be gated by an additional internal restriction or a bug in how provider tool policy is applied.

Environment

• OpenClaw version: 2026.4.25
• Surface: WebChat / Control UI
• Sender metadata observed by runtime:

{
  "label": "openclaw-control-ui",
  "id": "openclaw-control-ui"
}

What was configured

elevated sender allow rules

Both global and agent-level config were updated from:

"webchat": ["webchat"]

to:

"webchat": ["webchat", "openclaw-control-ui"]

This appears to have changed the failure mode away from the previous elevated allowFrom failure.

provider-level tool policy

Both global and agent-level config were updated with:

"byProvider": {
  "webchat": {
    "alsoAllow": ["exec", "process"]
  }
}

Gateway was restarted after each config change.

Observed behavior

After the elevated sender config fix, the prior error changed from elevated allowFrom failure to:

exec denied: allowlist miss

Even after adding provider-specific tool policy for webchat, the same allowlist miss error still occurs for basic commands such as:

openclaw --version
openclaw doctor --help

Why this looks like a bug / hidden policy layer

From config schema inspection:

• tools.elevated.allowFrom supports provider-keyed sender arrays
• tools.byProvider.* and agents.list.*.tools.byProvider.* support allow, alsoAllow, deny, and profile
• runtime config confirms the updated values are loaded

However, WebChat exec still fails with allowlist miss, which suggests either:

1. WebChat / Control UI does not use normal provider tool policy for exec
2. there is an additional internal hard restriction on exec for this surface
3. provider policy for WebChat is not being applied correctly

Expected behavior

If WebChat sender identity is allowed in tools.elevated.allowFrom.webchat and exec is explicitly allowed in tools.byProvider.webchat (plus the agent-level equivalent), then basic exec commands should be runnable from WebChat / Control UI.

Actual behavior

WebChat still returns:

exec denied: allowlist miss

Request

Please clarify whether WebChat / Control UI intentionally has an internal exec restriction separate from normal provider tool policy, or whether this is a bug/regression in tool policy application.