Antinuke

Anti-nuke watches the people who already have power in your server. When somebody deletes channels, hands out Administrator or wipes your emotes faster than a rule allows, it punishes them and posts an incident. It is aimed at a compromised staff account, not at strangers at the door — that is anti-raid's job. Every anti-nuke command is Server Owner only, so a granted Administrator permission does not reach it.

Prove it will actually fire

,antinuke check is the most useful command in this section, and the one to run first. It audits your live configuration and answers one question: if somebody started nuking right now, would anything happen?

It reports failures and warnings in a single embed, with a footer counting how many rules are armed. What it looks for:

Fix every failure before you trust anything on this page. A warning is worth reading but is not necessarily wrong — an empty whitelist is deliberate on some servers.

Arm your first rule

The most common actions have a subcommand of their own: channel, role, emote, botadd, grantadmin and removeadmin. Every other action is reached through ,antinuke rule <action> <on|off>, which takes the same flags and writes the same rule. The slash form offers the action as a picker, so you cannot mistype one.

Choose what each rule watches

The last four have no threshold on purpose. There is no acceptable number of times to hand Administrator to a stranger, or to sell the server's vanity URL, before something happens.

Set the threshold, the window and the punishment

Every rule that counts has two numbers. ++threshold is how many matching actions trip it, and ++window is how many seconds they have to land inside. A rule armed with no flags uses a threshold of 3 inside a 60 second window.

Wider windows catch a slow, patient nuke. Narrower ones only ever see a burst. A tight threshold on a busy server with active moderators is the usual cause of a false positive, which is what the whitelist and warn are for.

Each punishment needs a permission the bot actually holds, and ,antinuke check tells you when it does not:

Turn on the extra options a rule supports

Three flags are only accepted by the actions they make sense for. Asking for one elsewhere is refused with a message saying so.

++wide <on|off> applies to grantadmin and removeadmin. By default those rules watch Administrator alone. With wide on they also watch the permissions that usually come first — Ban Members, Kick Members, Moderate Members, Manage Server, Manage Channels, Manage Roles, Manage Webhooks, Manage Expressions, Manage Nicknames, Mention Everyone and View Audit Log. The incident embed names which one actually tripped it. Each rule reads its own flag, so widening grantadmin leaves removeadmin alone.

++countbot <on|off> applies to ban, kick, unban, grantadmin, removeadmin, role, rolecreate, channel and channelcreate. Actions the bot performs are normally excused, which also excuses a moderator who does the same thing by running the bot's own commands in a loop. With countbot on, an action a person ordered through the bot counts against them personally. Punishments the protection engine issues itself are never counted, so a rule can never trip on its own response.

++revert <on|off> applies to channelcreate, rolecreate, ban, unban, grantadmin, removeadmin, guild, webhook, integration and botadd. Read the next section before turning it on.

Undo what a trip already tells us how to undo

revert runs after the person is punished, never before. Removing their ability to act again is the actual fix, and restoring things while they still hold whatever let them act is a race you lose.

It only reverses what the triggering action itself carries: delete a channel, role, webhook or integration that was just created, re-ban somebody just unbanned, unban somebody just banned, take a granted admin-shaped permission back off, put a stripped one back on, or restore a server setting to its previous value. On botadd the invited bot is removed, and that one is on by default — pass ++revert off if you would rather keep the bot and only punish whoever added it.

Two more things it will never do. A kick cannot be undone, because Discord has no un-kick. A stolen vanity URL cannot be written back by a bot at all — the incident embed prints your old code so you can reclaim it by hand in Server Settings → Vanity URL, and it is worth doing quickly before somebody else takes the freed code.

Revert is also held back in two situations, and the incident embed says which one applied. It never runs on a rule armed as warn, because a dry run that deletes channels is not a dry run. And it never runs when the punishment itself was skipped, because the person is still in a position to do it all over again.

A revert pass is bounded. If it cannot finish, or it notices the same things being destroyed again, it stops and reports what it did not attempt in a follow-up summary rather than silently truncating.

Keep your staff off the punishment path

,antinuke whitelist takes add, remove, list and clear, and accepts either a user or a role. A whitelisted person's actions are exempt from every rule.

The server owner is never punishable, whether whitelisted or not. Discord's owner outranks everybody regardless of role position, and no bot can act against them.

Whitelisting a role above your own highest role is refused. Allowing it would let a member permanently exempt a role they do not control, which is a privilege escalation dressed as a config change.

Review and reset

,antinuke info lists every armed rule with its punishment, threshold, window and any extra options. Rules can also be armed and edited from the Anti-Nuke page of the ,config panel, which writes exactly what the commands write.

,antinuke reset turns every rule off at once. It does not clear the whitelist or the log channel.

Common issues

,antinuke check says a role sits at or above the bot. Drag the bot's own role higher in Server Settings → Roles. A tie is as unpunishable as being outranked.

A rule is armed but nothing happens. Most often the bot is missing View Audit Log. Run ,antinuke check — it names the cause.

stripstaff trips but removes nothing. Your staff-role list is empty. Add roles with ,staff add <role>.

A moderator got banned for doing their job. Whitelist them or the role, then raise the threshold or widen the window. Re-arm the rule as warn for a while if you want to watch it first.

Nothing appears in the log. Set a dedicated channel with ,antinuke log <channel> and confirm the bot can post there. The check reports an unpostable channel as a failure.