Channel permission overrides: how Discord resolves allow, deny, and inherit

Three states: allow, deny, inherit

Inside a channel's Permissions tab, each permission for each role or member has three states. A green check allows the permission, a red cross denies it, and a grey slash means "inherit" — make no statement here and let the next layer decide. Inherit is the default and is almost always the right choice. Overusing explicit allows and denies is what creates tangled setups.

The calculation order

Discord computes a member's final permissions in a fixed sequence. Understanding it removes most of the guesswork:

• Start with the server-wide permissions: the union of every role the member holds, including @everyone. If the member has Administrator, stop — they have everything.
• Apply the channel's override for @everyone: remove its denies, then add its allows.
• Combine the overrides for all of the member's other roles: collect every deny and every allow across those roles, remove the combined denies, then add the combined allows.
• Apply any override that targets the member directly, again removing denies and then adding allows.

The important consequence: allow beats deny between roles

Because role overrides are combined before they are applied, an allow on one of a member's roles beats a deny on another of their roles in the same channel. If "Staff" is denied Send Messages in a channel but "Event Host" is allowed to, a member holding both can send messages. Deny only wins when it is applied at a later layer than the allow, such as a member-specific override placed over a role allow.

Worked example: a private staff channel

Suppose you want a channel only moderators can see. The reliable recipe is two overrides. Deny View Channel for @everyone, then allow View Channel for the Moderator role. Every member starts from the server baseline, loses the ability to see the channel at the @everyone step, and moderators gain it back at the role step. You do not need to touch any other role.

The shortcut many admins try instead — leaving @everyone alone and denying View Channel for each non-staff role — breaks the moment you create a new role, because the new role inherits the open default. A whole category built this way, including the sync failures that undo it, is in locking channels without a lockout .

Categories and synced channels

Channels placed inside a category can be synced with it, in which case they use the category's overrides rather than their own. Changing a category's override then updates every synced channel at once. The moment you edit a single channel's permissions, it stops being synced, and later category changes no longer reach it. Audit a locked-down section by checking the category first, then looking for unsynced channels inside it.

Administrator ignores all of this

Everything above is skipped for members with the Administrator permission. They can see and use every channel regardless of overrides. If a "private" channel keeps showing up for someone who should not see it, check whether one of their roles carries Administrator before you debug the overrides themselves.

Who may edit overrides matters too

Rewriting a channel's overrides is one of the most powerful actions available, because it can expose private channels or lock out the whole server. In Discord, Manage Channels and Manage Permissions both allow it, bundled together with the harmless ability to rename a channel. The channel editor labels Manage Permissions; it is the Manage Roles flag. Perminator separates "edit channel settings" from "manage overrides" so a moderator can tidy channel names without being able to reshape who can see what.