---
title: Slack
description: Slack as a first-class, bidirectional channel. Mention to run, threaded replies, inbound attachments, repo binding from links, and results back in the thread.
sidebar:
  order: 2
---

Slack is a first-class channel, not a notifier. A run can begin, continue, and
finish entirely from Slack, and it enters the same durable command lane as the
web UI.

## Starting and continuing a run

1. **Mention or DM to start**

    An `@mention` or a direct message starts a run.

2. **Reply to continue**

    Replies thread under the run, with multi-turn continuity, reusing the thread's
    history and sandbox.

3. **Attachments ride the run**

    Inbound file attachments are attached to the run and render on the user's turn
    in the web timeline.

## Repository binding from links

GitHub links in a Slack message bind the run's repositories, validated against
the **same allowlist the web composer enforces**. The channel does not get a
weaker security posture than the web app; it shares the allowlist.

## Results back in the thread

Answers and artifacts flow back to the Slack thread:

- A Slack-started run posts a **Block Kit run card** with title and status, model,
  and owner or repository, plus an "Open in UseAgent" button.
- The card **updates in place** as the run moves from queued to running to
  completed, throttled, with a plain-text chunked fallback so the answer is never
  lost.
- Approvals are resolved in the web app today; in-thread Block Kit approvals
  are deliberately deferred.

## Scoped bring-up

A per-channel ingress allowlist scopes where Slack can start runs, so a workspace
can enable UseAgent in one channel before opening it more widely.

:::tip
Everything Slack does here rides shared machinery: the command lane, the thread
stream, and the outbox. That is why Slack behaves consistently with the web app
rather than being a parallel implementation.
:::