Discord

Discord is a native Crew channel — every DM thread is an isolated session with full tool access, streaming responses, and inline tool approval. Setup mirrors Slack, but the trust and allowlist model is stricter: deny-by-default with an explicit user allowlist.

1. Open Settings → Channels → Discord in the dashboard
2. Create a Discord bot in the Discord developer portal and copy the bot token
3. Paste the token into the dashboard panel
4. Add your Discord user ID to the Allowed users list
5. Click Save — the gateway restarts and connects

The dashboard shows a green status badge when connected.

Set the env var and configure the allowlist:

# In ~/.kiro/crew/.env
DISCORD_BOT_TOKEN=your-token-here

In ~/.kiro/crew/config.json:

{
  "discord": {
    "allowed_users": ["123456789012345678"]
  }
}

Then restart: kirocrew restart. Check status with kirocrew doctor.

Discord uses a Gateway WebSocket connection for inbound events (identify → heartbeat → message dispatch) and REST for outbound sends (post message, edit, react, ack component). No public URL is needed — Crew's process establishes and maintains the WebSocket.

Compared to Slack, the moving parts are:

Each Discord DM channel becomes its own session, keyed by discord:{agent}:direct:{user}:

• New DMs auto-open a session
• Follow-up messages continue the session
• Sessions time out per session.timeout_secs (default 30 min idle)
• Recovery, circuit breaker, and memory injection work exactly like every other session

Because the session is keyed on the user (not a thread), all messages from one user go into one continuous session. Discord DMs are conversational — the model fits.

Discord's control-plane surface is deny-by-default, even for the bot's owner. To interact with the bot from a Discord DM, the user must be in the allowlist.

Managed via config or the dashboard:

{
  "discord": {
    "allowed_users": ["123456789012345678", "234567890123456789"]
  }
}

Or through the dashboard's Discord settings panel. Every allowlist add is SEL-audited.

Why deny-by-default. Unlike Slack, where the owner ID gives a single hard-locked identity, Discord bot invites are cheap. A bot added to a public server with no allowlist would be exposed to anyone who could DM it. The allowlist forces a per-user opt-in.

The autonudge loop — the reactive self-check that reinjects instructions on an idle timer — is locked to the user's current session only on Discord. A nudge cannot fire against a user's older DM session, and a user not currently active gets nothing.

• Slack: nudges fire for any allowlisted session
• Discord: nudges fire only against the user's current session
• Dashboard slots: nudges fire against the specific slot

This asymmetry is intentional. Discord's channel model doesn't cleanly separate "this user's active work" from "this user's older threads", so Crew errs strict.

Interactive tool approval works via Discord's message component buttons:

• Approve — button posts an interaction that resolves the pending approval
• Reject — same, with the opposite outcome
• 2-hour timeout on the interactive prompt (auto-reject)

Follow-up messages during an approval prompt are queued. Sending !stop cancels the current turn (and any pending approval).

Approval mode matches the gateway's global mode:

• interactive — every tool call prompts
• auto (YOLO) — auto-approve all tool calls

Interactive-mode caveat. In interactive mode, Discord babysit loops cannot use tools — the unattended turn has no one to approve calls, so it falls through to deny-by-default. If you want tool-heavy Discord workflows, run the gateway in auto mode or use the dashboard / Slack for tool work.

Discord's platform caps messages at 2000 characters per message (max_message_chars: 2000 for the Discord transport). Long agent responses are automatically split. Interactive buttons are capped at 3 per Block Kit-style card (max_buttons: 3).

• Images — sent to the ACP vision channel, rendered inline
• Text files — inlined into the message
• Voice memos — transcribed if the file is audio
• Binary files — sent as file_send tool calls

Files sent by non-allowlisted users are silently dropped.

If your Discord bot runs in an organization with multiple accounts, the transport supports enterprise ID validation — analogous to Slack's Enterprise Grid check — but the primary defense is still the allowlist.

Discord group channels can be joined but must be enabled per-channel. In group channels:

• Only messages from allowlisted users are recorded (observe mode)
• Non-allowlisted user messages are silently dropped
• @-mention behavior is optional per channel

By default, only DM sessions are active. Group participation is opt-in.

The send_message MCP tool supports Discord targets:

• channel: "discord:{channel_id}" — post to a specific channel
• user: "discord:{user_id}" — post to a specific user's DM

Cron jobs and subagent completions can target Discord this way if the routing marker declares a Discord channel:

- [ ] Poll status  <!-- deliver:discord:{channel_id} -->

Discord's REST API has per-route rate limits. The transport respects them and backs off automatically. If you see repeated 429s in kirocrew doctor, the bot is being rate-limited — reduce message frequency or use fewer inline component updates.

Under discord.*: