Reviewed parent-category permission synchronization

Discord treats a child channel as synchronized when its complete permission-overwrite set matches its parent category, and later parent changes propagate while that equality remains. Changing the child independently breaks that relationship. This workflow deliberately models the complete replacement and future-propagation consequence instead of presenting synchronization as a harmless metadata toggle. See Discord's permission-syncing contract and Modify Channel endpoint.

Synchronization has no immediate-call path and does not inherit single-overwrite authority. Set capabilities.permissionSyncs: true, list every eligible direct child by exact ID in scopes.permissionSyncChannelIds, and select the independent permission-sync toolset. The exact child allowlist must remain within readScope.channelIds when that read allowlist exists. The child must be a text, announcement, forum, media, voice, or Stage channel with one live same-guild parent category; categories, directory channels, threads, direct messages, parentless channels, caller-selected copy sources, and batches are rejected.

1. Call plan_channel_permission_sync with the exact child ID, Discord audit-log reason, unique one-shot operation key, and literal acknowledgments that the complete child overwrite set will be replaced, later parent changes will propagate while synchronized, and concurrent permission editors have been stopped.
2. Review the verified application, bot, guild, child, and parent identities; complete child and parent overwrite counts; every changed role or member structural overwrite; protected-member boundary; current-child, parent, and prospective-child connector authority; privacy limitation; warnings; operation-key hash; and keyed digest.
3. If the action is none, the exact sets already match. Execution rechecks that proof but requests no confirmation, reserves no key, writes no activity, and sends no Discord mutation.
4. Call execute_channel_permission_sync with identical inputs plus the digest.
5. Approve the signed MCP confirmation only if the complete replacement, future propagation, stopped-concurrency boundary, every changed target, reason, one-shot key hash, and digest remain intended.
6. Review the exact child-parent synchronization proof, parent-baseline and supporting-evidence match, activity ID, and outcome before any follow-up permission work.

Planning verifies pinned application and bot identities, exact local scope, direct child and parent identity, guild ownership, exact connector membership, complete bounded roles, and both complete overwrite sets. Every referenced role target must exist in the complete role inventory. Changed member overwrites are checked against the protected-user denylist without fetching member profiles, returning usernames, or claiming exhaustive combined member-effective access analysis. Unknown future permission bits, known non-channel bits, duplicate or contradictory targets, incomplete evidence, and an excessive changed-target frontier fail closed.

The connector must have complete VIEW_CHANNEL, MANAGE_CHANNELS, and MANAGE_ROLES evidence on the current child and under the prospective copied set. It must have complete VIEW_CHANNEL evidence on the parent and hold every permission present in either outgoing parent bitfield there. This blocks copying authority the connector does not possess and prevents a reviewed replacement from hiding the child or removing the connector's ability to manage channels or roles. The planner evaluates the complete sets rather than sampling only changed entries.

The process-keyed digest binds the strict request and all three acknowledgments, one-shot operation-key hash, verified identities, complete child and parent overwrite sets, complete supporting role and membership evidence, structural delta, current, parent, and prospective authority, privacy claims, and warnings. A connector restart invalidates it. The MCP adapter rebuilds the plan before elicitation, the production facade rebuilds it to derive and durably claim the exact live parent, and the domain service rebuilds it again immediately before reservation and mutation.

Execution durably coordinates both exact channels across connector processes sharing the activity-state root, atomically reserves the key, and appends pending content-free activity before one non-retried PATCH whose body contains only the complete reviewed permission_overwrites array. It requires the exact child response, unchanged guild and parent binding, exact response overwrites, and a fresh complete child, parent, guild, connector-member, role, authority, and synchronization readback. Exact synchronization with unrelated supporting-evidence or parent-baseline drift is reported as completed-with-drift, never silently collapsed into a pristine success.

Only a known pre-response Discord client rejection other than timeout or rate limiting can settle as failed. Rate limiting, timeout, transport ambiguity, server failure, malformed or mismatched success evidence, missing synchronization proof, or local finalization failure is uncertain and potentially completed. The key remains spent, both exact channel claims remain available for operator review, overlapping same-channel permission work is blocked after uncertainty, and the connector never retries, guesses, compensates, or rolls back automatically. The stopped-concurrency acknowledgment remains necessary because durable local claims cannot pause a Discord administrator, another bot, or a connector using a different state root.

Plans expose exact changed target IDs and transient role names only for deliberate human review. Activity and operation records may retain only the verified application, bot, guild, child, and parent IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. They never retain overwrite targets, permission values, role, member, guild, or channel names, audit reasons, raw operation keys, or raw Discord payloads.

Canonical source: docs/reference.md