Slack approvals don't seem to propagate back to the gateway

[sonic raft]

OpenClaw 2026.4.15 (041266a)
in channels: slack I have
"capabilities": {
"interactiveReplies": true
},
"execApprovals": {
"enabled": true,
"approvers": [
"UslkjdaC"
],
"target": "dm"
}

I see the buttons fine in the Slack UI but then if I either click always-approve or type the command /approve f8528414 allow-always nothing happens on the gateway side. what am I missing?

[sullen ember]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[coarse gyro]

Let me check the docs and the Slack approval code path.

I found the approval docs. Now I’m checking the Slack command/interactivity plumbing, because “buttons render but gateway sees nothing” usually means the Slack app can post messages but its callbacks are not reaching OpenClaw.

I think there are 3 Slack-specific gotchas here:

1. capabilities.interactiveReplies is not the exec approval switch
   That only enables agent-authored Slack UI like [[slack_buttons: ...]]. Exec approvals use channels.slack.execApprovals.*.

2. In Slack, the manual fallback is usually not bare /approve ...
   If you're using the default single Slack slash command, the command is:

/openclaw /approve f8528414 allow-always

Bare /approve ... only works if you enabled native Slack commands and registered them in the Slack app (channels.slack.commands.native: true).

3. If the buttons render but clicks never reach the gateway, the callback plumbing is wrong
   Most common checks:

• HTTP mode: Slack Events, Interactivity, and Slash Commands must all point to the same OpenClaw webhook URL, usually something like:
  https://your-host/slack/events
• HTTP mode also needs the correct signingSecret
• Socket mode needs both botToken and appToken, Socket Mode enabled in Slack, and Interactivity enabled in the Slack app settings

Also, if you're using a named Slack account, put this under the account block, not top-level:

channels: {
  slack: {
    accounts: {
      work: {
        execApprovals: {
          enabled: true,
          approvers: ["U123..."],
          target: "dm",

        },
      },
    },
  },
}

So the two biggest likely misses are:

• you should be using /openclaw /approve ..., not /approve ...
• Slack Interactivity / Request URL is not actually wired back to the gateway

Docs:

• https://docs.openclaw.ai/channels/slack#exec-approvals-in-slack
• https://docs.openclaw.ai/channels/slack#commands-and-slash-behavior
• https://docs.openclaw.ai/tools/exec-approvals

If you paste your Slack mode (socket vs http) and the full channels.slack block, I can sanity check it fast.

[sonic raft]

"channels": {
"slack": {
"mode": "socket",
"webhookPath": "/slack/events",
"enabled": true,
"botToken": "xoxb-xxx",
"appToken": "xapp-xxx",
"userTokenReadOnly": true,
"dmPolicy": "allowlist",
"allowFrom": [
"U69xxxxxx"
],
"groupPolicy": "allowlist",
"channels": {
"C0A6xxxxxx": {
"requireMention": true,
"users": [
"U69Jxxxxxx",
"U68xxxxxxx"
]
}
},
"streaming": {
"mode": "partial",
"nativeTransport": true
},
"replyToModeByChatType": {
"direct": "off",
"channel": "all"
},
"capabilities": {
"interactiveReplies": true
},
"execApprovals": {
"enabled": true,
"approvers": [
"U69Jxxxxxx"
],
"target": "dm"
}
}

let's ignore the command for now, if the buttons worked that would be great.

confirmed that interactivity is on in slack in the app config as well

"webhookPath": "/slack/events", how can I tell if this gets hit?

[coarse gyro]

Let me check one more thing in the source, I want to see whether Slack native approval clicks in socket mode rely on any extra auth or routing beyond the config you pasted.

Yeah, with that config I don’t think you’re missing an approval-specific knob.

The big thing is this:

you’re on Slack mode: "socket", and there are current regressions where Slack Socket Mode connects fine, outbound works, but no inbound events get delivered. When that happens, approval cards render, but button clicks never make it back to the gateway.

That matches your symptom almost perfectly.

Relevant issues:

• https://github.com/openclaw/openclaw/issues/67496
• https://github.com/openclaw/openclaw/issues/66989

Quick sanity check:

• click the button
• then run openclaw channels logs --channel slack

If you only see stuff like slack socket mode connected and no inbound interaction/event log at all, it’s that bug.

Best workaround right now

Switch Slack from Socket Mode to HTTP Request URLs.

Docs:

• https://docs.openclaw.ai/channels/slack#http-request-urls
• https://docs.openclaw.ai/channels/slack#exec-approvals-in-slack

In HTTP mode, make sure all 3 Slack callbacks hit the same endpoint:

• Events API request URL
• Interactivity request URL
• Slash command URL

Usually all to something like:

https://your-host/slack/events

with channels.slack.mode: "http" plus signingSecret.

So, short version: I think this is a known Slack socket-mode inbound-events bug, not a bad execApprovals config.

If you want, paste the HTTP-mode block you plan to switch to and I’ll sanity check it before you flip it.

In mode: "socket", webhookPath does not matter for Slack inbound events.

So the short answer is: it won’t get hit, because Slack is not POSTing to /slack/events in socket mode.

That path is only relevant in mode: "http".

How to tell if inbound Slack events are arriving in socket mode

Watch the Slack channel logs while you:

• send the bot a DM
• mention it in a channel
• click an approval button

openclaw channels logs --channel slack

If socket mode is healthy, you should see inbound Slack event/activity logs, not just:

• starting provider
• slack socket mode connected

If you only ever see connected and then silence, that strongly points to the socket-mode inbound-events bug.

So, for your current config:

• webhookPath: "/slack/events" is basically irrelevant
• the thing to check is whether any inbound Slack event shows up in openclaw channels logs --channel slack

If you switch to HTTP mode later, then /slack/events becomes the right thing to inspect, usually via your reverse proxy access logs or Slack’s Request URL validation.

[sonic raft]

gateway/channels/slack
slack:interaction action=openclaw:reply_button:1:2 type=button user=U6xxxxxx channel=D0ATcxxxxx
8:16:28 AM
info
gateway/ws
⇄ res ✓ exec.approval.waitDecision 16013ms conn=fc6685a0…0cf1 id=84da5158…6278
8:16:35 AM
warn
[WARN] socket-mode:SlackWebSocket:3 A pong wasn't received from the server before the timeout of 5000ms!
[WARN] socket-mode:SlackWebSocket:3 A pong wasn't received from the server before the timeout of 5000ms!

if this is a known bug with slack sockets I can wait for a fix and use the openclaw ui until then for approvals

[coarse gyro]

Let me sanity check that log pattern, because this looks slightly different from “no inbound events at all”.

Yep, this changes the diagnosis a bit.

Those logs mean:

• slack:interaction ... → the button click is reaching OpenClaw
• exec.approval.waitDecision ... right after → the approval wait path is probably resolving
• the scary bit is the repeated
  A pong wasn't received from the server before the timeout of 5000ms!

So this no longer looks like “Slack never delivered the click”. It looks much more like a Slack socket-mode reliability bug, where the interaction arrives, then the socket gets unhealthy and follow-up/resume behavior goes sideways.

Relevant tracking:

• pong timeout / silent loss: https://github.com/openclaw/openclaw/issues/58519
• broader socket-mode inbound weirdness: https://github.com/openclaw/openclaw/issues/67496 and https://github.com/openclaw/openclaw/issues/66989

So yes, I think your conclusion is reasonable: