openclaw.connect('slack')

# api.slack.com/apps → your app → Basic Information
#   Generate an App-Level Token with scope:  connections:write
# Then: OAuth & Permissions → install to workspace → copy the Bot User OAuth Token

`connections:write` スコープこそが、それをbot tokenではなくapp-level tokenにしています。SlackがSocket Modeを提示しない場合、たいていこのスコープが原因です。

{
  channels: {
    slack: {
      mode: "socket",
      appToken: { source: "env", id: "SLACK_APP_TOKEN" },
      botToken: { source: "env", id: "SLACK_BOT_TOKEN" },
    },
  },
}

どちらもSecretRefにします。SlackのトークンはIPに紐づかない単なるBearer資格情報で、漏れればローテーションするまで誰でも使えます。設定ファイルには置かないでください。

# Minimum bot scopes:
#   app_mentions:read   channels:history   channels:read
#   chat:write          commands           groups:history
#   groups:read         im:history         im:read
#   users:read

この一覧は提案ではなく下限です。特に `channels:history` が欠けると、投稿はできるが読めないボットになります。権限の問題ではなく、エージェントが文脈を無視しているように見えます。

openclaw config patch --file ./slack.socket.json5
openclaw gateway restart
openclaw gateway status

見るべきは `gateway status` です。app-level tokenの設定ミスは接続時に失敗し、その失敗はSlack側ではなくここにしか現れません。

{
  channels: {
    slack: {
      mode: "http",
      botToken:      { source: "env", id: "SLACK_BOT_TOKEN" },
      signingSecret: { source: "env", id: "SLACK_SIGNING_SECRET" },
      webhookPath: "/slack/events",
    },
  },
}

signing secretは、リクエストが本当にSlackから来たことを検証する手段です。検証がなければ、そのWebhookパスはエージェントに指示を出せる無認証のエンドポイントになります。省略はゲートウェイを開放するのと同等だと考えてください。

# Channel allowlists are keyed by Slack ID, never by name.
# Right-click a channel → View channel details → the ID is at the bottom.
#
#   "C12345678"     correct
#   "#engineering"  silently matches nothing

`#名前` をキーにしてもエラーにはならず、単に何にも一致しません。結果として、有効化したかったまさにそのチャンネルでエージェントが沈黙します。Slack設定で最も多い間違いです。