Reviewed native message forwarding

Native message forwarding has no immediate-call path. Set capabilities.messageForwarding: true, pin both identity.applicationId and identity.botId, list every eligible direct source in scopes.messageForwardSourceChannelIds, and list every eligible direct target in scopes.messageForwardTargetChannelIds. Both dedicated allowlists must remain subsets of any configured read-channel boundary. Sources and targets may be direct GUILD_TEXT or GUILD_ANNOUNCEMENT channels, but they must be different exact channels. Same-guild forwarding is the default; crossing a guild boundary additionally requires capabilities.crossGuildMessageForwarding: true and independent guild and channel scope at both endpoints.

Planning requires confirmed Message Content intent, verified application and bot identities, complete guild, member, role, channel, and overwrite evidence, source VIEW_CHANNEL plus READ_MESSAGE_HISTORY, and target VIEW_CHANNEL, READ_MESSAGE_HISTORY, plus SEND_MESSAGES. Complete permission decisions expose unknown bits and warnings rather than silently treating them as authority. Target read history is mandatory because execution independently fetches the created message rather than trusting the create response. An age-restricted source may forward only to an age-restricted target, and this downgrade check runs before source content is read. Threads, polls, call messages, activity-bearing messages, system types, already forwarded messages, existing snapshots, malformed attachment evidence, missing reply references, incomplete permissions, and unbounded, malformed, or unexpected rich message data fail closed. Eligible sources are exact default, reply, chat-input command result, or context-menu command result messages.

1. Call plan_message_forward with the exact source channel, source message, target channel, and a unique one-shot operation key.
2. Review the verified application and bot IDs, exact source and target guilds and channels, age-restriction boundary, untrusted source preview and rich-data counts, both complete permission decisions including unknown bits, Message Content intent, guild-boundary decision, immutable snapshot exposure, empty-mention and notification-suppression controls, deterministic nonce, warnings, operation-key hash, and keyed digest.
3. Call execute_message_forward with identical inputs plus the digest.
4. Approve the signed MCP confirmation only if every exact identity, message, endpoint, permission, exposure, boundary, delivery control, warning, operation-key hash, and digest remains intended.
5. Review the returned exact target message ID and URL, response-snapshot match, independent readback-snapshot match, activity ID, and outcome before any follow-up.

The process-keyed HMAC digest binds the normalized request, one-shot key hash, deterministic nonce, verified identities, Message Content intent, exact source message body and stable attachment metadata, embeds, components, mentions, stickers, source reference, both endpoint guild and channel identities, relevant roles and overwrites, complete effective permissions, cross-guild decision, and forced delivery controls. Expiring attachment delivery URLs are excluded from the stable projection so harmless signed-URL rotation does not invalidate review, while every stable attachment field remains bound. Rich JSON is recursively and aggregately bounded, hostile object keys remain ordinary digest-bound data, and a connector restart invalidates the digest.

Execution rebuilds the plan before approval and again before mutation, acquires durable claims over the exact source message and target channel, atomically reserves the one-shot key, and appends pending content-free activity. It then sends one non-retried create-message request containing only an exact forward reference, a deterministic nonce with enforcement enabled, an empty allowed-mentions policy, and the notification-suppression flag. The response must be an empty outer message authored by the verified bot with the exact forward reference, exactly one immutable snapshot equal to the reviewed stable source projection, and only the required snapshot and notification-suppression flags. A second exact target-message read must prove the same contract.

A known pre-response Discord 4xx other than request timeout or rate limiting is failed. Request timeout, rate limiting, transport failure, Discord 5xx, malformed or mismatched response, snapshot divergence, readback failure, or any other indeterminate state is uncertain and potentially completed. The receipt preserves a known target message ID when response evidence supplies one. Every reserved key remains permanently spent, and uncertainty retains the durable source-message and target-channel claims for credential-free operator review. The connector never retries, deletes the created message, compensates, or rolls back automatically.

Source content, attachment filenames and stable metadata, embeds, components, mentions, stickers, author and guild or channel names, raw payloads, and attachment URLs are transient review evidence only. They never enter activity records, operation receipts, coordination state, diagnostics, telemetry, or errors. Durable message-forward activity contains only exact Discord IDs, the deterministic nonce, plan digest, operation-key hash, timestamp, fixed status and verification values, activity ID, and sanitized error category. Ordinary message reads expose only snapshot count and an explicit redaction marker, never the forwarded snapshot body. See Discord's forwarding fields, message snapshots, message references, and message flags.

Canonical source: docs/reference.md