PR #71025: fix(slack): resolve exec approval decisions from interactive buttons

• Repository: openclaw/openclaw
• Author: marusan03
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/71025

Description (problem / solution / changelog)

Summary

• Problem: Slack exec approval buttons (Allow Once / Always Allow / Deny) are received by the gateway but the approval decision is never forwarded to exec.approval.resolve. Commands time out after 30 minutes despite the user clicking the button.
• Why it matters: Exec approval via Slack is completely non-functional. Users must fall back to Control UI to approve commands.
• What changed: Added exec approval resolution logic to handleSlackBlockAction in the Slack plugin, mirroring the existing Telegram implementation. After handleSlackPluginBindingApproval returns false for a reply action, the code now parses the interaction data with parseExecApprovalCommandText and, if matched, calls resolveApprovalOverGateway.
• What did NOT change (scope boundary): No changes to the approval request delivery path, Control UI behavior, Telegram plugin, or gateway approval infrastructure.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #71023
• Related #66916
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: handleSlackBlockAction() in interactions.block-actions.ts does not check for exec approval command text after handleSlackPluginBindingApproval() returns false. The button value (/approve <id> allow-once) falls through to enqueueSlackBlockActionEvent() and is delivered to the agent as plain text instead of being resolved over the gateway.
• Missing detection / guardrail: No code path exists in the Slack plugin to parse exec approval commands from interactive button values and call resolveApprovalOverGateway().
• Contributing context: The Telegram plugin has the correct implementation in bot-handlers.runtime.ts — it calls parseExecApprovalCommandText() on callback data and resolves via resolveApprovalOverGateway(). The Slack plugin was missing this equivalent code path.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/slack/src/monitor/events/interactions.block-actions.test.ts
• Scenario the test should lock in: When a reply button interaction contains a valid exec approval command (/approve <id> allow-once), resolveApprovalOverGateway should be called with the correct approval ID and decision, and the event should not be enqueued as a system event.
• Why this is the smallest reliable guardrail: A seam test can mock resolveApprovalOverGateway and verify it is called with correct params without requiring a live Slack connection.
• Existing test that already covers this (if any): None — existing block-actions tests do not cover exec approval button interactions.
• If no new test is added, why not: The fix mirrors the established Telegram pattern; a follow-up test PR is recommended.

User-visible / Behavior Changes

• Clicking exec approval buttons (Allow Once / Always Allow / Deny) in Slack now resolves the approval and executes the command, matching Control UI behavior.
• Previously, clicking these buttons had no effect and the approval timed out after 30 minutes.

Diagram (if applicable)

Before:
[Slack button click] -> handleSlackPluginBindingApproval (false)
                     -> enqueueSlackBlockActionEvent (plain text)
                     -> agent receives "/approve <id> allow-once" as text
                     -> incomplete turn / timeout

After:
[Slack button click] -> handleSlackPluginBindingApproval (false)
                     -> parseExecApprovalCommandText (match!)
                     -> resolveApprovalOverGateway
                     -> command executes

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No — resolveApprovalOverGateway uses the existing gateway WebSocket client
• Command/tool execution surface changed? No — approval decisions were already reachable via Control UI; this enables the same path from Slack
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS 26.2 (arm64)
• Runtime/container: Node 22.22.2
• Model/provider: ollama/qwen3.6:27b
• Integration/channel: Slack (Socket Mode)
• Relevant config (redacted):

  {
    "channels": {
      "slack": {
        "enabled": true,
        "execApprovals": {
          "enabled": true,
          "approvers": ["U06TP4R5VRS"],
          "target": "both"
        }
      }
    },
    "tools": {
      "exec": {
        "security": "allowlist",
        "ask": "on-miss"
      }
    }
  }

Steps

1. Send @OpenClaw ping -c 4 localhost in a Slack channel
2. Wait for exec approval buttons to appear
3. Click "Allow Once"

Expected

• Command executes immediately after approval

Actual

• Before fix: approval times out after 30 minutes, command never executes
• After fix: command executes immediately

Evidence

• Gateway log before fix: exec.approval.waitDecision 1799998ms (30-minute timeout)
• Gateway log after fix: slack: exec approval resolved: <id> -> allow-once followed by command execution
• Control UI approval for the same request works correctly (confirming gateway infrastructure is functional)

Human Verification (required)

• Verified scenarios: Slack DM and channel exec approval with Allow Once button — command executes after approval
• Edge cases checked: Unauthorized sender receives ephemeral "not authorized" message; plugin approval IDs (plugin:*) fall back correctly
• What you did not verify: Always Allow persistence across sessions; Deny button behavior (expected to work symmetrically)

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: updateSlackInteractionMessage may fail if the original message was deleted or the bot lacks permissions.
  • Mitigation: Wrapped in try/catch with best-effort semantics (same pattern used elsewhere in the Slack plugin).

Changed files

• extensions/slack/src/monitor/events/interactions.block-actions.ts (modified, +57/-1)
• extensions/slack/src/monitor/events/interactions.test.ts (modified, +10/-2)

PR #71028: fix(slack): resolve exec approval button clicks via gateway instead of system events

• Repository: openclaw/openclaw
• Author: Bartok9
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/71028

Description (problem / solution / changelog)

Summary

When a user clicks an exec approval button (Allow Once / Allow Always / Deny) in Slack, the approval decision is enqueued as a plain system event via enqueueSlackBlockActionEvent() instead of being resolved over the gateway WebSocket via exec.approval.resolve. This causes the approval to never reach the waiting agent, resulting in a 30-minute timeout.

Fixes #71023

Root Cause

handleSlackBlockAction() in interactions.block-actions.ts checks for plugin binding approvals via handleSlackPluginBindingApproval(), which correctly returns false for exec approvals (they aren't plugin bindings). The function then falls through to enqueueSlackBlockActionEvent(), which delivers the approval decision as a plain system event — the gateway never sees it.

The Telegram extension handles this correctly: after the plugin binding check, it calls parseExecApprovalCommandText() on the callback data and routes matches through resolveApprovalOverGateway().

Fix

New file: extensions/slack/src/exec-approval-resolver.ts

• Mirrors Telegram's exec-approval-resolver.ts — calls resolveApprovalOverGateway() with Slack-specific context

Modified: extensions/slack/src/monitor/events/interactions.block-actions.ts

• After the plugin binding check and before enqueueSlackBlockActionEvent(), parses the button value with parseExecApprovalCommandText()
• If it's an exec approval, verifies sender authorization via existing isSlackExecApprovalApprover() / isSlackExecApprovalAuthorizedSender()
• Calls resolveSlackExecApproval() to resolve via gateway WebSocket
• Clears approval buttons from the Slack message after resolution
• Blocks unauthorized senders with a verbose log entry and early return

New test: extensions/slack/src/exec-approval-resolver.test.ts

• Verifies the resolver correctly forwards to resolveApprovalOverGateway() with proper params
• Tests plugin prefix routing, allowPluginFallback passthrough, and Slack-specific display name

Flow (before → after)

Before:

1. User clicks "Allow Once" → Slack fires block action
2. handleSlackPluginBindingApproval() → false (not a binding)
3. Falls to enqueueSlackBlockActionEvent() → plain system event
4. Agent never receives approval → 30 min timeout

After:

1. User clicks "Allow Once" → Slack fires block action
2. handleSlackPluginBindingApproval() → false (not a binding)
3. parseExecApprovalCommandText(pluginInteractionData) → matches approval command
4. Authorization check → resolveSlackExecApproval() → resolved via gateway WebSocket ✅
5. Approval buttons cleared from message

Changed files

• extensions/slack/src/exec-approval-resolver.test.ts (added, +109/-0)
• extensions/slack/src/exec-approval-resolver.ts (added, +26/-0)
• extensions/slack/src/monitor/events/interactions.block-actions.ts (modified, +55/-1)