Channels
Drive a project from Slack — messages spawn sessions and the agent replies in-thread.
A channel connects a chat workspace to a project so you can run the agent from chat. Connect Slack to a project, and a message or mention spawns a session; the agent replies in the thread. Follow-up messages in that thread continue the same session.
- Connect Slack with
kortix channels connector from the project's Channels page in the dashboard. Both offer the same two modes: one-click via the Kortix-managed Slack app (the CLI prints an "Add to Slack" install link — open it, pick the workspace, click Allow), or bring your own Slack app (--manual: a bot token + signing secret, via flags,SLACK_BOT_TOKEN/SLACK_SIGNING_SECRETenv vars, or stdin). - Credentials are stored as project secrets (e.g.
SLACK_BOT_TOKEN,SLACK_SIGNING_SECRET) — never in the repo. - The agent talks to Slack through the Executor. Connecting Slack
auto-materializes a
slackconnector (providerchannel): the agent's Slack calls — posting, file upload/download, history, reactions, search — run through the gateway with the bot token resolved server-side, so the token is never exposed inside the sandbox. Theslackconnector also shows up in the project's Connectors, where you control who can use it.
Note
Channels are configured through the dashboard, CLI, and secrets — not
through the manifest (kortix.yaml/kortix.toml). v2 removes channel
declarations from the schema outright; the slack connector auto-materializes
on connect, you don't declare it.
Who the agent runs as
By default, every Slack sender — the first message in a channel, a thread
follow-up, or a button click — must be linked to a Kortix account that has
access to the project before the agent will act for them. Link your identity
once with the /kortix login slash command (or the button on the prompt
below); it opens a short-lived, private browser link that connects your
Slack user to a Kortix account.
If there's no linked mapping yet, the agent doesn't run — it posts an ephemeral prompt nudging the sender to connect (or, if they're linked but not a member of the project's account, to request access) instead of replying.
Legacy
Deployments that disable this requirement fall back to the older behavior: every message runs as a stand-in for the project account's owner, regardless of who actually sent it. This is legacy, non-default behavior — the identity requirement is on by default.