setup tips & tricks — Slack × CMA webhook bridge

To route Slack @mentions to Claude Managed Agents, a bridge server captures signed `/slack/events` webhooks, creates a stateless CMA session, and later posts results back into the originating Slack thread using stored session metadata targeting `slack_channel` and `slack_thread_ts`.

A Claude Managed Agents webhook posts results back to a Slack thread by routing `session.status_idled` signals through a `/cma-webhook` endpoint, retrieving session metadata, and calling Slack `chat.postMessage` with the correct bot token to target the original `slack_thread_ts`.

Slack webhook event idempotency and HMAC verification are needed to dedupe Slack retry payloads and validate request signatures, ensuring the bridge fires session creation only once per mention without waiting for the model run to complete.

Yes, a Slack CMA webhook bridge requires correct bot token scopes and handles token prefix differences such as `xoxb-` versus `xapp-` to ensure the `chat.postMessage` call has the authorization needed to post replies into the originating thread.

Slack mention webhooks require a 3-second acknowledgment, so the bridge must fire CMA session creation immediately and return a response without waiting for the model run, relying on the later `/cma-webhook` callback to post the final results.

To filter unrelated Claude Managed Agents sessions when posting back to Slack threads, the `/cma-webhook` endpoint uses a retrieve-then-filter approach on session metadata, ensuring only sessions matching the originating `slack_channel` and `slack_thread_ts` receive the `chat.postMessage` reply.