Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading from 2026.3.28 to 2026.3.31, the gateway blocks agent exec calls with a "user-denied" state even when the Slack exec approvals toggle is enabled in the UI and per-agent tools.exec config is set.

Steps to reproduce

1. Upgrade OpenClaw from 2026.3.28 to 2026.3.31.
2. 2. Have an agent (e.g. "briefing") with a script in its workspace and no explicit tools.exec config in openclaw.json.
3. 3. Enable Slack exec approvals in the UI (channels.slack.execApprovals.enabled: true).
4. 4. Send a message to the agent via Slack that triggers a script/exec call.
5. 5. Click "Allow Always" on the Slack approval button when it appears.
6. 6. Observe: gateway logs show exec state as user-denied; agent receives no script output and returns no results.

Expected behavior

Clicking "Allow Always" in Slack should persist exec approval so the gateway allows subsequent exec calls without prompting again. The agent should successfully run the script and return results.

Actual behavior

Gateway logs show exec approval state as user-denied immediately after "Allow Always" is clicked. The approval is not persisted — clicking the button again results in the same denial. The agent returns no output. Root cause appears to be a conflict between the new channels.slack.execApprovals gate introduced in 2026.3.31 and the exec-approvals.sock socket owned by the desktop app: the socket caches a denied state that overrides the UI toggle. Additionally, the new per-agent tools.exec enforcement means agents without an explicit tools.exec block in openclaw.json have no exec policy, which exacerbates the failure.

OpenClaw version

2026.3.31

Operating system

macOS Tahoe 26.3.1(a)

Install method

openclaw update

Model

anthropic/claude-sonnet-4-6 (via agent)

Provider / routing chain

openclaw gateway (LaunchAgent) -> Slack channel

Additional provider/model setup details

No response

Logs, screenshots, and evidence

**Gateway log excerpt:**

[exec] agent=briefing state=user-denied pattern=/Users/Fergus/.openclaw/.venv/bin/python
[exec] agent=briefing state=user-denied pattern=/Users/Fergus/.openclaw/.venv/bin/python


**Relevant `openclaw.json` config at time of failure (no per-agent exec block):**

"channels": {
  "slack": {
    "execApprovals": { "enabled": true, "approvers": ["U0ANC3Q55GF"] }
  }
}


**Workaround:** Kill the OpenClaw desktop app process (removes `exec-approvals.sock`), set `exec-approvals.json` defaults to `{"security": "none", "ask": "off"}`, and add explicit per-agent exec config:

"agents": { "list": [{ "id": "briefing", "tools": { "exec": { "ask": "off", "security": "full" } } }] }

Impact and severity

Any user upgrading from pre-2026.3.31 who has agents relying on exec/script calls via Slack. Severity: High — exec calls are completely blocked, agents silently return no results. Frequency: 100% reproducible after upgrade if no explicit per-agent tools.exec config exists. The failure is silent from the user's perspective (no error shown in Slack, agent just doesn't respond with data).

Additional information

Two separate exec approval systems appear to have been introduced/changed in 2026.3.31 simultaneously:

1. channels.slack.execApprovals — new Slack button-based approval gate
2. 2. exec-approvals.sock — Unix socket owned by the desktop app managing exec-approvals.json
      These two systems conflict: the socket caches a user-denied state that overrides the UI toggle, and the "Allow Always" Slack button uses chat.update which may not reliably signal approval back to the gateway. Additionally, 2026.3.31 started honoring per-agent tools.exec defaults — agents without this config block have no clear exec policy, causing the gateway to fall back to deny. Migration guide or upgrade notes warning about these breaking changes would have prevented this.