@symerian/symi 3.0.16 → 3.0.18

package/docs/concepts/multi-agent.md

@@ -90,7 +90,6 @@ Each agent gets its own workspace with `SYMICORE.md`, `AGENTS.md`, and optional
 
 Create one account per agent on your preferred channels:
 
-- Discord: one bot per agent, enable Message Content Intent, copy each token.
 - Telegram: one bot per agent via BotFather, copy each token.
 - WhatsApp: link each phone number per account.
 
@@ -98,8 +97,6 @@ Create one account per agent on your preferred channels:
 symi channels login --channel whatsapp --account work
 ```
 
-See channel guides: [Discord](/channels/discord), [Telegram](/channels/telegram), [WhatsApp](/channels/whatsapp).
-
   </Step>
 
   <Step title="Add agents, accounts, and bindings">
@@ -175,12 +172,10 @@ Bindings are **deterministic** and **most-specific wins**:
 
 1. `peer` match (exact DM/group/channel id)
 2. `parentPeer` match (thread inheritance)
-3. `guildId + roles` (Discord role routing)
-4. `guildId` (Discord)
-5. `teamId` (Slack)
-6. `accountId` match for a channel
-7. channel-level match (`accountId: "*"`)
-8. fallback to default agent (`agents.list[].default`, else first list entry, default: `main`)
+3. `teamId` (Slack)
+4. `accountId` match for a channel
+5. channel-level match (`accountId: "*"`)
+6. fallback to default agent (`agents.list[].default`, else first list entry, default: `main`)
 
 If multiple bindings match in the same tier, the first one in config order wins.
 If a binding sets multiple match fields (for example `peer` + `guildId`), all specified fields are required (`AND` semantics).
@@ -200,10 +195,6 @@ multiple phone numbers without mixing sessions.
 
 ## Platform examples
 
-### Discord bots per agent
-
-Each Discord bot account maps to a unique `accountId`. Bind each account to an agent and keep allowlists per bot.
-
 ```json5
 {
   agents: {
@@ -213,15 +204,11 @@ Each Discord bot account maps to a unique `accountId`. Bind each account to an a
     ],
   },
   bindings: [
-    { agentId: "main", match: { channel: "discord", accountId: "default" } },
-    { agentId: "coding", match: { channel: "discord", accountId: "coding" } },
   ],
   channels: {
-    discord: {
       groupPolicy: "allowlist",
       accounts: {
         default: {
-          token: "DISCORD_BOT_TOKEN_MAIN",
           guilds: {
             "123456789012345678": {
               channels: {
@@ -231,7 +218,6 @@ Each Discord bot account maps to a unique `accountId`. Bind each account to an a
           },
         },
         coding: {
-          token: "DISCORD_BOT_TOKEN_CODING",
           guilds: {
             "123456789012345678": {
               channels: {
@@ -249,7 +235,6 @@ Each Discord bot account maps to a unique `accountId`. Bind each account to an a
 Notes:
 
 - Invite each bot to the guild and enable Message Content Intent.
-- Tokens live in `channels.discord.accounts.<id>.token` (default account can use `DISCORD_BOT_TOKEN`).
 
 ### Telegram bots per agent
 

package/docs/concepts/queue.md

@@ -36,7 +36,6 @@ Inbound messages can steer the current run, wait for a followup turn, or do both
 Steer-backlog means you can get a followup response after the steered run, so
 streaming surfaces can look like duplicates. Prefer `collect`/`steer` if you want
 one response per inbound message.
-Send `/queue collect` as a standalone command (per-session) or set `messages.queue.byChannel.discord: "collect"`.
 
 Defaults (when unset in config):
 
@@ -52,7 +51,6 @@ Configure globally or per channel via `messages.queue`:
       debounceMs: 1000,
       cap: 20,
       drop: "summarize",
-      byChannel: { discord: "collect" },
     },
   },
 }
@@ -77,7 +75,6 @@ Defaults: `debounceMs: 1000`, `cap: 20`, `drop: summarize`.
 
 ## Scope and guarantees
 
-- Applies to auto-reply agent runs across all inbound channels that use the gateway reply pipeline (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat, etc.).
 - Default lane (`main`) is process-wide for inbound + main heartbeats; set `agents.defaults.maxConcurrent` to allow multiple sessions in parallel.
 - Additional lanes may exist (e.g. `cron`, `subagent`) so background jobs can run in parallel without blocking inbound replies.
 - Per-session lanes guarantee that only one agent run touches a given session at a time.

package/docs/concepts/retry.md

@@ -21,14 +21,10 @@ title: "Retry Policy"
 - Jitter: 0.1 (10 percent)
 - Provider defaults:
   - Telegram min delay: 400 ms
-  - Discord min delay: 500 ms
 
 ## Behavior
 
-### Discord
-
 - Retries only on rate-limit errors (HTTP 429).
-- Uses Discord `retry_after` when available, otherwise exponential backoff.
 
 ### Telegram
 
@@ -51,7 +47,6 @@ Set retry policy per provider in `~/.symi/symi.json`:
         jitter: 0.1,
       },
     },
-    discord: {
       retry: {
         attempts: 3,
         minDelayMs: 500,

package/docs/concepts/session-tool.md

@@ -47,7 +47,6 @@ Row shape (JSON):
 
 - `key`: session key (string)
 - `kind`: `main | group | cron | hook | node | other`
-- `channel`: `whatsapp | telegram | discord | signal | imessage | webchat | internal | unknown`
 - `displayName` (group display label if available)
 - `updatedAt` (ms)
 - `sessionId`
@@ -121,7 +120,6 @@ Policy-based blocking by channel/chat type (not per session id).
     "sendPolicy": {
       "rules": [
         {
-          "match": { "channel": "discord", "chatType": "group" },
           "action": "deny"
         }
       ],

package/docs/concepts/session.md

@@ -106,7 +106,6 @@ the workspace is writable. See [Memory](/concepts/memory) and
 - Daily reset: defaults to **4:00 AM local time on the gateway host**. A session is stale once its last update is earlier than the most recent daily reset time.
 - Idle reset (optional): `idleMinutes` adds a sliding idle window. When both daily and idle resets are configured, **whichever expires first** forces a new session.
 - Legacy idle-only: if you set `session.idleMinutes` without any `session.reset`/`resetByType` config, Symi stays in idle-only mode for backward compatibility.
-- Per-type overrides (optional): `resetByType` lets you override the policy for `direct`, `group`, and `thread` sessions (thread = Slack/Discord threads, Telegram topics, Matrix threads when provided by the connector).
 - Per-channel overrides (optional): `resetByChannel` overrides the reset policy for a channel (applies to all session types for that channel and takes precedence over `reset`/`resetByType`).
 - Reset triggers: exact `/new` or `/reset` (plus any extras in `resetTriggers`) start a fresh session id and pass the remainder of the message through. `/new <model>` accepts a model alias, `provider/model`, or provider name (fuzzy match) to set the new session model. If `/new` or `/reset` is sent alone, Symi runs a short “hello” greeting turn to confirm the reset.
 - Manual reset: delete specific keys from the store or remove the JSONL transcript; the next message recreates them.
@@ -121,10 +120,8 @@ Block delivery for specific session types without listing individual ids.
   session: {
     sendPolicy: {
       rules: [
-        { action: "deny", match: { channel: "discord", chatType: "group" } },
         { action: "deny", match: { keyPrefix: "cron:" } },
         // Match the raw session key (including the `agent:<id>:` prefix).
-        { action: "deny", match: { rawKeyPrefix: "agent:main:discord:" } },
       ],
       default: "allow",
     },
@@ -147,9 +144,7 @@ Runtime override (owner only):
   session: {
     scope: "per-sender", // keep group keys separate
     dmScope: "main", // DM continuity (set per-channel-peer/per-account-channel-peer for shared inboxes)
-    identityLinks: {
-      alice: ["telegram:123456789", "discord:987654321012345678"],
-    },
+    identityLinks: {},
     reset: {
       // Defaults: mode=daily, atHour=4 (gateway host local time).
       // If you also set idleMinutes, whichever expires first wins.
@@ -162,9 +157,7 @@ Runtime override (owner only):
       direct: { mode: "idle", idleMinutes: 240 },
       group: { mode: "idle", idleMinutes: 120 },
     },
-    resetByChannel: {
-      discord: { mode: "idle", idleMinutes: 10080 },
-    },
+    resetByChannel: {},
     resetTriggers: ["/new", "/reset"],
     store: "~/.symi/agents/{agentId}/sessions/sessions.json",
     mainKey: "main",

package/docs/concepts/streaming.md

@@ -45,7 +45,6 @@ Legend:
 - `agents.defaults.blockStreamingCoalesce`: `{ minChars?, maxChars?, idleMs? }` (merge streamed blocks before send).
 - Channel hard cap: `*.textChunkLimit` (e.g., `channels.whatsapp.textChunkLimit`).
 - Channel chunk mode: `*.chunkMode` (`length` default, `newline` splits on blank lines (paragraph boundaries) before length chunking).
-- Discord soft cap: `channels.discord.maxLinesPerMessage` (default 17) splits tall replies to avoid UI clipping.
 
 **Boundary semantics:**
 
@@ -78,7 +77,6 @@ progressive output.
 - Joiner is derived from `blockStreamingChunk.breakPreference`
   (`paragraph` → `\n\n`, `newline` → `\n`, `sentence` → space).
 - Channel overrides are available via `*.blockStreamingCoalesce` (including per-account configs).
-- Default coalesce `minChars` is bumped to 1500 for Signal/Slack/Discord unless overridden.
 
 ## Human-like pacing between blocks
 

package/docs/concepts/system-prompt.md

@@ -123,7 +123,6 @@ This keeps the base prompt small while still enabling targeted skill usage.
 
 When available, the system prompt includes a **Documentation** section that points to the
 local Symi docs directory (either `docs/` in the repo workspace or the bundled npm
-package docs) and also notes the public mirror, source repo, community Discord, and
 SymiHub ([https://symihub.com](https://symihub.com)) for skills discovery. The prompt instructs the model to consult local docs first
 for Symi behavior, commands, configuration, or architecture, and to run
 `symi status` itself when possible (asking the user only when it lacks access).

package/docs/concepts/timezone.md

@@ -62,7 +62,6 @@ You can override this with:
 
 ## Tool payloads (raw provider data + normalized fields)
 
-Tool calls (`channels.discord.readMessages`, `channels.slack.readMessages`, etc.) return **raw provider timestamps**.
 We also attach normalized fields for consistency:
 
 - `timestampMs` (UTC epoch milliseconds)

package/docs/date-time.md

@@ -116,7 +116,6 @@ Channel tools return **provider-native timestamps** and add normalized fields fo
 Raw provider fields are preserved so nothing is lost.
 
 - Slack: epoch-like strings from the API
-- Discord: UTC ISO timestamps
 - Telegram/WhatsApp: provider-specific numeric/ISO timestamps
 
 If you need local time, convert it downstream using the known timezone.

package/docs/docs.json

@@ -1,7 +1,6 @@
 {
   "$schema": "https://mintlify.com/docs.json",
   "name": "Symi",
-  "description": "Self-hosted gateway that connects WhatsApp, Telegram, Discord, iMessage, and more to AI coding agents. Run a single Gateway process on your own machine and message your AI assistant from anywhere.",
   "theme": "mint",
   "icons": {
     "library": "lucide"
@@ -123,10 +122,7 @@
       "source": "/message",
       "destination": "/cli/message"
     },
-    {
-      "source": "/providers/discord",
-      "destination": "/channels/discord"
-    },
+    {},
     {
       "source": "/providers/googlechat",
       "destination": "/channels/googlechat"
@@ -307,10 +303,7 @@
       "source": "/device-models",
       "destination": "/reference/device-models"
     },
-    {
-      "source": "/discord",
-      "destination": "/channels/discord"
-    },
+    {},
     {
       "source": "/discovery",
       "destination": "/gateway/discovery"
@@ -883,7 +876,6 @@
                 "pages": [
                   "channels/whatsapp",
                   "channels/telegram",
-                  "channels/discord",
                   "channels/irc",
                   "channels/slack",
                   "channels/feishu",
@@ -1397,7 +1389,6 @@
                 "pages": [
                   "zh-CN/channels/whatsapp",
                   "zh-CN/channels/telegram",
-                  "zh-CN/channels/discord",
                   "zh-CN/channels/slack",
                   "zh-CN/channels/feishu",
                   "zh-CN/channels/googlechat",

package/docs/experiments/plans/cron-add-hardening.md

@@ -44,7 +44,6 @@ Recent gateway logs show repeated `cron.add` failures with invalid parameters (m
 
 - **Normalization:** wrapped `data`/`job` payloads are unwrapped; `schedule.kind` and `payload.kind` are inferred when safe.
 - **Defaults:** safe defaults are applied for `wakeMode` and `sessionTarget` when missing.
-- **Providers:** Discord/Slack/Signal/iMessage are now consistently surfaced across CLI/UI.
 
 See [Cron jobs](/automation/cron-jobs) for the normalized shape and examples.
 

package/docs/experiments/plans/session-binding-channel-agnostic.md

@@ -16,7 +16,6 @@ Goal:
 
 - make subagent bound session routing a core capability
 - keep channel specific behavior in adapters
-- avoid regressions in normal Discord behavior
 
 ## Why this exists
 
@@ -24,7 +23,6 @@ Current behavior mixes:
 
 - completion content policy
 - destination routing policy
-- Discord specific details
 
 This caused edge cases such as:
 
@@ -114,10 +112,6 @@ For this iteration:
 - only `task_completion` is routed through this new path
 - existing paths for other event kinds remain as-is
 
-### 3. Keep Discord as adapter
-
-Discord remains the first adapter implementation.
-
 Adapter responsibilities:
 
 - create/reuse thread conversations
@@ -130,7 +124,6 @@ Adapter responsibilities:
 Required in this iteration:
 
 - refresh token usage when reusing existing thread binding manager
-- record outbound activity for webhook based Discord sends
 - stop implicit main channel fallback when a bound thread destination is selected for session mode completion
 
 ### 5. Preserve current runtime safety defaults
@@ -139,11 +132,8 @@ No behavior change for users with thread bound spawn disabled.
 
 Defaults stay:
 
-- `channels.discord.threadBindings.spawnSubagentSessions = false`
-
 Result:
 
-- normal Discord users stay on current behavior
 - new core path affects only bound session completion routing where enabled
 
 ## Not in iteration 1
@@ -151,7 +141,6 @@ Result:
 Explicitly deferred:
 
 - ACP binding targets (`targetKind: "acp"`)
-- new channel adapters beyond Discord
 - global replacement of all delivery paths (`spawn_ack`, future `subagent_message`)
 - protocol level changes
 - store migration/versioning redesign for all binding persistence
@@ -175,14 +164,12 @@ These invariants are mandatory for iteration 1.
 Compatibility target:
 
 - no regression for users with thread bound spawning off
-- no change to non-Discord channels in this iteration
 
 Rollout:
 
 1. Land interfaces and router behind current feature gates.
-2. Route Discord completion mode bound deliveries through router.
-3. Keep legacy path for non-bound flows.
-4. Verify with targeted tests and canary runtime logs.
+2. Keep legacy path for non-bound flows.
+3. Verify with targeted tests and canary runtime logs.
 
 ## Tests required in iteration 1
 
@@ -202,16 +189,8 @@ Core:
 - `src/infra/outbound/bound-delivery-router.ts` (new)
 - `src/agents/subagent-announce.ts` (completion destination resolution integration)
 
-Discord adapter and runtime:
-
-- `src/discord/monitor/thread-bindings.manager.ts`
-- `src/discord/monitor/reply-delivery.ts`
-- `src/discord/send.outbound.ts`
-
 Tests:
 
-- `src/discord/monitor/provider*.test.ts`
-- `src/discord/monitor/reply-delivery.test.ts`
 - `src/agents/subagent-announce.format.e2e.test.ts`
 
 ## Done criteria for iteration 1

package/docs/experiments/plans/thread-bound-subagents.md

@@ -1,5 +1,4 @@
 ---
-summary: "Discord thread bound subagent sessions with plugin lifecycle hooks, routing, and config kill switches"
 owner: "onutc"
 status: "implemented"
 last_updated: "2026-02-21"
@@ -10,12 +9,8 @@ title: "Thread Bound Subagents"
 
 ## Overview
 
-This feature lets users interact with spawned subagents directly inside Discord threads.
-
 Instead of only waiting for a completion summary in the parent session, users can move into a dedicated thread that routes messages to the spawned subagent session. Replies are sent in-thread with a thread bound persona.
 
-The implementation is split between channel agnostic core lifecycle hooks and Discord specific extension behavior.
-
 ## Goals
 
 - Allow direct thread conversation with a spawned subagent session.
@@ -27,26 +22,21 @@ The implementation is split between channel agnostic core lifecycle hooks and Di
 ## Out of scope
 
 - New ACP protocol features.
-- Non Discord thread binding implementations in this document.
-- New bot accounts or app level Discord identity changes.
 
 ## What shipped
 
 - `sessions_spawn` supports `thread: true` and `mode: "run" | "session"`.
 - Spawn flow supports persistent thread bound sessions.
-- Discord thread binding manager supports bind, unbind, TTL sweep, and persistence.
 - Plugin hook lifecycle for subagents:
   - `subagent_spawning`
   - `subagent_spawned`
   - `subagent_delivery_target`
   - `subagent_ended`
-- Discord extension implements thread auto bind, delivery target override, and unbind on end.
 - Text commands for manual control:
   - `/focus`
   - `/unfocus`
   - `/agents`
   - `/session ttl`
-- Global and Discord scoped enablement and TTL controls, including a global kill switch.
 
 ## Core concepts
 
@@ -91,12 +81,8 @@ The manager is responsible for:
 
 ### Core and extension boundary
 
-Core (`src/agents/*`) does not directly depend on Discord routing internals.
-
 Core emits lifecycle intent through plugin hooks.
 
-Discord extension (`extensions/discord/src/subagent-hooks.ts`) implements Discord specific behavior:
-
 - pre spawn thread bind preparation
 - completion delivery target override to bound thread
 - unbind on subagent end
@@ -111,7 +97,6 @@ Discord extension (`extensions/discord/src/subagent-hooks.ts`) implements Discor
    - post run registration event
 3. `subagent_delivery_target`
    - completion routing override hook
-   - can redirect completion delivery to bound Discord thread origin
 4. `subagent_ended`
    - cleanup and unbind signal
 
@@ -147,8 +132,6 @@ Migration guardrails:
 
 Binding state path:
 
-- `${stateDir}/discord/thread-bindings.json`
-
 Record shape contains:
 
 - account, channel, thread
@@ -163,32 +146,22 @@ State is stored on `globalThis` to keep one shared registry across ESM and Jiti
 
 ### Effective precedence
 
-For Discord thread binding options, account override wins, then channel, then global session default, then built in fallback.
-
-- account: `channels.discord.accounts.<id>.threadBindings.<key>`
-- channel: `channels.discord.threadBindings.<key>`
 - global: `session.threadBindings.<key>`
 
 ### Keys
 
-| Key                                                     | Scope           | Default         | Notes                                     |
-| ------------------------------------------------------- | --------------- | --------------- | ----------------------------------------- |
-| `session.threadBindings.enabled`                        | global          | `true`          | master default kill switch                |
-| `session.threadBindings.ttlHours`                       | global          | `24`            | default auto unfocus TTL                  |
-| `channels.discord.threadBindings.enabled`               | channel/account | inherits global | Discord override kill switch              |
-| `channels.discord.threadBindings.ttlHours`              | channel/account | inherits global | Discord TTL override                      |
-| `channels.discord.threadBindings.spawnSubagentSessions` | channel/account | `false`         | opt in for `thread: true` spawn auto bind |
+| Key                               | Scope  | Default | Notes                      |
+| --------------------------------- | ------ | ------- | -------------------------- |
+| `session.threadBindings.enabled`  | global | `true`  | master default kill switch |
+| `session.threadBindings.ttlHours` | global | `24`    | default auto unfocus TTL   |
 
 ### Runtime effect of enable switch
 
-When effective `enabled` is false for a Discord account:
-
 - provider creates a noop thread binding manager for runtime wiring
 - no real manager is registered for lookup by account id
 - inbound bound thread routing is effectively disabled
 - completion routing overrides do not resolve bound thread origins
 - `/focus`, `/unfocus`, and thread binding specific operations report unavailable
-- `thread: true` spawn path returns actionable error from Discord hook layer
 
 ## Flow and behavior
 
@@ -196,30 +169,26 @@ When effective `enabled` is false for a Discord account:
 
 1. Spawn validates mode and permissions.
 2. `subagent_spawning` hook runs.
-3. Discord extension checks effective flags:
    - thread bindings enabled
    - `spawnSubagentSessions` enabled
-4. Extension attempts auto bind and thread creation.
-5. If bind fails:
+3. Extension attempts auto bind and thread creation.
+4. If bind fails:
    - spawn returns error
    - provisional child session is deleted
-6. If bind succeeds:
+5. If bind succeeds:
    - child run starts
    - run is registered with spawn mode
 
 ### Manual focus and unfocus
 
 - `/focus <target>`
-  - Discord only
   - resolves subagent or session target
   - binds current or created thread to target session
 - `/unfocus`
-  - Discord thread only
   - unbinds current thread
 
 ### Inbound routing
 
-- Discord preflight checks current thread id against thread binding manager.
 - If bound, effective session routing uses bound target session key.
 - If not bound, normal routing path is used.
 
@@ -232,7 +201,6 @@ When effective `enabled` is false for a Discord account:
 ### Completion routing
 
 - Core completion flow calls `subagent_delivery_target`.
-- Discord extension returns bound thread origin when it can resolve one.
 - Core merges hook origin with requester origin and delivers completion.
 
 ### Cleanup
@@ -260,7 +228,6 @@ Cleanup behavior includes unbind and optional farewell messaging.
 
 Notes:
 
-- `/session ttl` is currently Discord thread focused behavior.
 - Thread intro and farewell text are generated by thread binding message helpers.
 
 ## Failure handling and safety
@@ -281,27 +248,14 @@ Notes:
 - `src/agents/subagent-registry-cleanup.ts`
 - `src/agents/subagent-registry-completion.ts`
 
-### Discord runtime
-
-- `src/discord/monitor/provider.ts`
-- `src/discord/monitor/thread-bindings.manager.ts`
-- `src/discord/monitor/thread-bindings.state.ts`
-- `src/discord/monitor/thread-bindings.lifecycle.ts`
-- `src/discord/monitor/thread-bindings.messages.ts`
-- `src/discord/monitor/message-handler.preflight.ts`
-- `src/discord/monitor/message-handler.process.ts`
-- `src/discord/monitor/reply-delivery.ts`
-
 ### Plugin hooks and extension
 
 - `src/plugins/types.ts`
 - `src/plugins/hooks.ts`
-- `extensions/discord/src/subagent-hooks.ts`
 
 ### Config and schema
 
 - `src/config/types.base.ts`
-- `src/config/types.discord.ts`
 - `src/config/zod-schema.session.ts`
 - `src/config/zod-schema.providers-core.ts`
 - `src/config/schema.help.ts`
@@ -309,12 +263,6 @@ Notes:
 
 ## Test coverage highlights
 
-- `extensions/discord/src/subagent-hooks.test.ts`
-- `src/discord/monitor/thread-bindings.ttl.test.ts`
-- `src/discord/monitor/thread-bindings.shared-state.test.ts`
-- `src/discord/monitor/reply-delivery.test.ts`
-- `src/discord/monitor/message-handler.preflight.test.ts`
-- `src/discord/monitor/message-handler.process.test.ts`
 - `src/auto-reply/reply/commands-subagents-focus.test.ts`
 - `src/auto-reply/reply/commands-session-ttl.test.ts`
 - `src/agents/subagent-registry.steer-restart.test.ts`
@@ -323,16 +271,11 @@ Notes:
 ## Operational summary
 
 - Use `session.threadBindings.enabled` as the global kill switch default.
-- Use `channels.discord.threadBindings.enabled` and account overrides for selective enablement.
 - Keep `spawnSubagentSessions` opt in for thread auto spawn behavior.
 - Use TTL settings for automatic unfocus policy control.
 
-This model keeps subagent lifecycle orchestration generic while giving Discord a full thread bound interaction path.
-
 ## Related plan
 
 For channel agnostic SessionBinding architecture and scoped iteration planning, see:
 
 - `docs/experiments/plans/session-binding-channel-agnostic.md`
-
-ACP remains a next step in that plan and is intentionally not implemented in this shipped Discord thread-bound flow.

package/docs/gateway/configuration-examples.md

@@ -121,7 +121,6 @@ Save to `~/.symi/symi.json` and you can DM the bot from that number.
       byChannel: {
         whatsapp: "collect",
         telegram: "collect",
-        discord: "collect",
         slack: "collect",
         signal: "collect",
         imessage: "collect",
@@ -160,7 +159,6 @@ Save to `~/.symi/symi.json` and you can DM the bot from that number.
       idleMinutes: 60,
     },
     resetByChannel: {
-      discord: { mode: "idle", idleMinutes: 10080 },
     },
     resetTriggers: ["/new", "/reset"],
     store: "~/.symi/agents/default/sessions/sessions.json",
@@ -173,7 +171,6 @@ Save to `~/.symi/symi.json` and you can DM the bot from that number.
     typingIntervalSeconds: 5,
     sendPolicy: {
       default: "allow",
-      rules: [{ action: "deny", match: { channel: "discord", chatType: "group" } }],
     },
   },
 
@@ -196,9 +193,7 @@ Save to `~/.symi/symi.json` and you can DM the bot from that number.
       groups: { "*": { requireMention: true } },
     },
 
-    discord: {
       enabled: true,
-      token: "YOUR_DISCORD_BOT_TOKEN",
       dm: { enabled: true, allowFrom: ["steipete"] },
       guilds: {
         "123456789012345678": {
@@ -314,7 +309,6 @@ Save to `~/.symi/symi.json` and you can DM the bot from that number.
       allowFrom: {
         whatsapp: ["+15555550123"],
         telegram: ["123456789"],
-        discord: ["steipete"],
         slack: ["U123"],
         signal: ["+15555550123"],
         imessage: ["user@example.com"],
@@ -451,7 +445,6 @@ Save to `~/.symi/symi.json` and you can DM the bot from that number.
       botToken: "YOUR_TOKEN",
       allowFrom: ["123456789"],
     },
-    discord: {
       enabled: true,
       token: "YOUR_TOKEN",
       dm: { allowFrom: ["yourname"] },
@@ -476,10 +469,7 @@ If more than one person can DM your bot (multiple entries in `allowFrom`, pairin
       allowFrom: ["+15555550123", "+15555550124"],
     },
 
-    // Example: Discord multi-user inbox
-    discord: {
       enabled: true,
-      token: "YOUR_DISCORD_BOT_TOKEN",
       dm: { enabled: true, allowFrom: ["alice", "bob"] },
     },
   },