Skip to main content

​
Overview

​
How a response is decided

The engine receives Discord events, attempts to attribute them through View Audit Log, checks the explicit whitelist, and evaluates the module policy. Activity windows are separated by actor, module, and action; cooldown helps prevent repeating a punishment during a burst already contained. If Discord has not yet verified the actor, Headless must not punish a random person. Security logs retain detection, enforcement, failures, cooldowns, whitelist changes, backups, and restores.

​
Observed activity and enforcement

Anti-Nuke records more activity than it can automatically punish. Expand the scope below to see which events are observed and which can trigger enforcement.
The list of recorded events is broader than the set of actions with automatic enforcement. Detecting an event does not mean Headless will punish someone.
Anti-Nuke records channel and thread changes; roles and memberships; bans, kicks, prune, timeouts, and voice moves; webhooks; emojis and stickers; invites; server updates, scheduled events, and AutoMod; and individual or bulk message deletions. Automatic enforcement is limited to bot additions, created/deleted channels or threads, deleted roles, bans, kicks, prune, created webhooks, deleted emojis or stickers, deleted AutoMod rules, and destructive bulk-delete bursts.

​
Coordinated activity

In addition to actor-attributed activity, the engine can correlate qualified events from multiple accounts within an internal window. This is not an exemption or a policy configurable through the eight module commands; Headless does not publish the correlation thresholds.
These are separate layers. Sentinel handles Headless content filters, while native AutoMod rules are managed in Discord. See the content-safety guide for the actual engines, bounds, and exemptions. Anti-Nuke’s automod_weakening detection watches changes to native rules but does not create them or moderate messages.Sentinel applies message analysis only while enabled. Its response also depends on mode, Simulation, the relevant engine, and effective Discord permissions; the dedicated guide documents the source-verified bounds and action behavior.The .automod and .automod content-exemptions commands require the server owner or configured Headless owner and open a panel in the current channel. Use a private staff channel. The dedicated guide explains each exemption scope, the .automod announcement-role command, and why native Discord rules must be managed in Discord.

​
Configure Anti-Nuke

​
Separate access controls

The server owner manages access and owner-only operations. Anti-Nuke Admins can configure most settings but are not exempt from protections. Fake Permissions authorizes compatible virtual Headless command checks; it does not change native Discord permissions or create Anti-Nuke exceptions. .an admins requires native Manage Server; reset confirmations revalidate the actor.
Anti-Nuke Admin, the whitelist, native Discord permissions, and Fake Permissions are separate controls. Configuration access does not add an account to the whitelist.

​
Anti-Nuke Admin access

​
Whitelist exemptions

The whitelist exempts only accounts explicitly added; it does not grant administrative access. Verify the target before saving an exemption.
The whitelist exempts an added account from Anti-Nuke protections. Grant that exception only to trusted people or bots; it is different from Anti-Nuke Admin access.
Historical Spanish response confirming a whitelist addition and trigger bypass; the actor and target mentions are redacted.

Historical Headless reply captured before the response copy was updated to English; the actor and target mentions are redacted.

​
Smart Setup and profiles

The built-in recommendation is read-only; it does not save or apply changes. Open Smart Setup in Dashboard → Anti-Nuke → Smart Setup as the owner or an Anti-Nuke Admin. The preview shows the analysis and changed fields; it expires after 10 minutes, is bound to the session and server, and is invalidated if the configuration revision changes. Cancel does not persist the plan.
The recommendation is an ordered heuristic, not an audit: first High-Admin / Gang for at least three unmanaged roles (excluding @everyone) with Administrator; then Maximum at 10,000 members; Gaming at 35 unmanaged roles or 12 bots; Business / Staff when a role name contains staff, team, business, or empresa; Creator at 6 bots; otherwise Community. The first matching rule wins.
No profile makes a role trusted or creates admins, whitelist entries, or Fake Permissions. Community, Gaming, High-Admin / Gang, Creator, and Business / Staff apply stripstaff; Maximum applies ban and the strictest security baseline. Applying a standard profile enables Anti-Nuke in Auto mode and turns Simulation off; review the preview first.
  • Community: balanced baseline (balanced); base punishment stripstaff.
  • Gaming: strict protection for active servers; base punishment stripstaff.
  • High-Admin / Gang: reinforces servers with many Administrator roles; base punishment stripstaff.
  • Creator: reinforces configurable protections for creator communities; base punishment stripstaff.
  • Business / Staff: strict configuration for staff teams; base punishment stripstaff.
  • Maximum Security: enables the strongest available baseline and uses ban as its base punishment.
  • Custom: keeps the current configuration, applies only reviewed decisions, and uses stripstaff as its base punishment.
For voice communities, limit Manage Channels and other escalation permissions to trusted roles: this permission can let an actor disrupt or reconfigure channels.
Standard Smart Setup profiles enable Auto and turn Simulation off. Anti-Nuke Admins can run .an max, which enables Auto, turns Simulation off, sets global punishment to ban, and enables critical modules and triggers. Review the preview and settings before confirming.

​
Monitor, Auto, and Simulation

The recommended initial setup is Monitor with Simulation enabled. Monitor records activity without punishment; Simulation tests detections without changing members, roles, channels, or bots. Auto applies real responses when Simulation is disabled. Switching to Auto and using .an strict require the owner. .an on restores the last saved mode and may re-enable Auto.
Start with Monitor and Simulation enabled. Review detections, permissions, and role hierarchy before allowing automatic responses.

​
Informational test

.an test records an informational test without applying punishment. It also enables the engine if it was off.

​
Module options

Each subcommand accepts on, off, or status. Flags depend on the module’s registered capabilities; the signatures below match Headless’s current parser. botadd has no threshold, configurable punishment, or --command flag.

​
.antinuke ban

​
.antinuke kick

​
.antinuke role

​
.antinuke channel

​
.antinuke emoji

​
.antinuke webhook

​
.antinuke

--threshold sets how many actions within a module’s window trigger a response. Available thresholds accept 1–50; neither vanity nor botadd accepts --threshold.
--do selects none, warn, jail, kick, ban, or stripstaff. botadd has no configurable punishment.
The --command flag counts moderation actions started through Headless commands; --command is supported only by ban, kick, and role.

​
Available modules

Each module keeps its own configuration. Subcommands accept on, off, and status; for botadd, only on and off change configuration, while status is a read-only query.
The ban, kick, and role modules accept thresholds, punishments, and --command, which can count actions started through Headless commands.
channel protects channel creation and deletion; emoji protects emoji deletion; and webhook protects webhook creation. They accept thresholds and punishments, but not --command.
vanity watches URL changes and allows a punishment, but Discord does not let Headless restore the URL (.antinuke vanity on --do stripstaff). For botadd, on/off toggle the setting and status only reads it; in Auto, Headless may remove an unauthorized bot when Discord permissions and hierarchy allow it.
Headless confirms that the Anti-Nuke vanity module was enabled with ban punishment; the user's mention is redacted.

Actual Headless reply to .antinuke vanity on --do ban; the user's mention is redacted.

Before choosing stripstaff, configure and review protected roles with .bind staff and .bind staff list.

​
Prefix commands and syntax

The prefix group is registered as .antinuke; .an is a shorter alias. It also accepts .anti-nuke, .sentinel, .sent, and .sen. The examples use the public prefix ..
  • .an shows group help; .an status and .an monitor check status and monitoring signals.
  • .antinuke config shows this server’s configuration. This read-only query is available to the owner or an Anti-Nuke Admin.
  • .antinuke list [category=all] opens paginated guild lists or a category detail; omit the category to query all.
  • .an access opens the Anti-Nuke Admin and whitelist panel.
  • .antinuke admin [user] [action=toggle] accepts toggle, add, or remove; omitting it toggles access. It is owner-only and does not change the whitelist.
  • .an admins lists admins and requires native Manage Server.
  • .antinuke whitelist [target] [action=toggle] accepts toggle, add, or remove; omitting it toggles the exception. Only the owner can change it; the target can be a member or an external bot ID.
  • .an whitelist list and .an whitelist users are read-only queries available to the owner or an Anti-Nuke Admin. Whitelist mutations, .an whitelist here @user, and .an whitelist everyone @user are owner-only.
  • .antinuke permissions <grant|remove> <permission> [--do <none|warn|jail|kick|ban|stripstaff>] configures the response for watched permissions; owner or Anti-Nuke Admin access is required. .an perms is an alias.
  • Each module has its own syntax card under Module options; use only the flags listed for that module. For botadd, on and off change the setting; .antinuke botadd status only reads it.
  • .an mode monitor|auto changes the mode; selecting Auto is owner-only. .an on restores the last mode and .an off disables Anti-Nuke (owner-only).
  • .an strict is owner-only and may start real enforcement. .an max is available to Anti-Nuke Admins and can also start real enforcement.
  • .an punishment [action] checks the global punishment; changing it is owner-only. .an instant on|off|status [ban_threshold] [ban_window] is owner-only and accepts 2–10 bans in a 10–120-second window.
  • .an logs [#channel] checks or changes dedicated logs and requires Anti-Nuke Admin.
  • .an alerts on|off|status [#channel] [dm-on|dm-off] configures owner alerts and is owner-only.
  • .an backup status|list|create|show|preview|restore|delete [ID]|on|off|every [hours] checks, creates, previews, schedules, or deletes snapshots; a real restore requires the owner and an explicit ID.
  • .an reset whitelist|bans requests confirmation, rechecks the owner or Anti-Nuke Admin, and can clear the whitelist or unban everyone and remove hardbans; .an clearwhitelist is another confirmed reset that only clears the whitelist.

​
.antinuke list

​
.antinuke botadd

The status query does not change configuration. Use on or off only when you intend to change the module state.
Headless confirms that the Anti-Nuke botadd module was enabled; the user's mention is redacted.

Actual Headless reply (in English) to .antinuke botadd on; the user's mention is redacted.

​
.antinuke permissions

See the Headless Commands catalog for current commands and aliases.

​
Staff roles and alerts

stripstaff removes configured staff roles that Headless can manage under current permissions and hierarchy. .bind staff @role toggles a role in the shared list used by Anti-Nuke Strip Staff and Dashboard Staff Roles; .bind staff list displays the list. The legacy settings staff alias may exist on installations that still expose it. .an restorestaff @member attempts to return saved staff roles, but cannot bypass permissions, hierarchy, or roles that no longer exist. Owner alerts can go to a channel and, if enabled, DMs; dedicated security logs retain evidence and do not change policy by themselves. Member protection DM: the first explicit Anti-Nuke activation enables this option if the owner has not initialized it before; later activations preserve the owner’s choice. While Sentinel is enabled and the option remains on, each new human member receives a best-effort informational DM. Delivery runs separately and does not delay join protection. A member who cannot receive DMs is silently skipped. The built-in copy starts with Headless · Active protection, explains the protection, and uses a staff-managed footer. When settings are loaded, Headless replaces only the exact former built-in Spanish strings; customized text is preserved.

​
Commands

​
Slash commands

Headless registers /antinuke recommend, status, access, list, admins, monitor, backup, backupnow, backuplast, backuptest, backuprestore, mode, disable, botadd, logs, alerts, instant, dashboard, admin, whitelist, reset, and punishment. Queries marked private by their handler respond ephemerally. Most commands require the owner or an Anti-Nuke Admin. Unlike the prefix .an admins, which requires native Manage Server, /antinuke admins uses the owner or Anti-Nuke Admin configuration gate. /antinuke admin, whitelist, backuprestore, disable, logs, alerts, instant, punishment, and selecting Auto in mode require the owner. /antinuke reset uses confirmation and rechecks the actor but does not use the same owner-only gate as those commands. Note: Run slash commands from Discord’s command interface. Check their options and permissions in the catalog; most require the owner or an Anti-Nuke Admin and private queries respond ephemerally.
.an reset bans can unban every member and remove hardbans after confirmation. Verify the target server and review the impact before confirming this irreversible action.

​
Backups and recovery

Snapshots may include roles, channels, permission overwrites, and role-to-member assignments. The default schedule creates one every 6 hours and keeps 12 retained copies. Each capture is limited to 250 resources and 5,000 member-role links; the view reports omissions. Viewing, creating, previewing, scheduling, and deleting snapshots requires Anti-Nuke configuration access. Only a real restore requires the server owner or Headless owner; previews are available to members with configuration access. A real restore also needs an explicit ID. A preview does not change Discord or guarantee a perfect reconstruction: resources may have new IDs, and Discord still applies hierarchy, capacity, and rate limits.

​
View and create snapshots

The subcommand accepts actions such as status, list, create, show, preview, restore, delete, on, off, and every. Use an ID only for actions that target a specific snapshot.
Also works: .antinuke backup list

​
Preview a restoration

A preview calculates the changes without modifying Discord. Use the ID shown in the snapshot list.
The limits and differences shown in a preview can change before a real restoration; review the result again immediately before applying it.

​
Restore a snapshot

Only the server owner or Headless owner can run a real restoration, and an existing snapshot ID is required.
Partial failures are logged, but restoration is not transactional and does not automatically undo changes Discord already accepted. Check the server and ID before continuing.

​
Schedule snapshots

Scheduling uses hours and the number of retained snapshots. The command clamps values to the ranges supported by Headless.

​
Discord permissions and limits

View Audit Log is essential for attribution. Depending on the response, Headless may also need Manage Roles, Manage Channels, Manage Webhooks, Ban Members, Kick Members, or Moderate Members. The bot role must be above what it manages. Headless cannot punish the owner, manage higher roles, or prevent an action Discord has already accepted. Review partial results and failures in the logs.

​
Safe initial setup

1

Analyze without changing settings

Run .an recommend; it does not save changes.
2

Preview Smart Setup

In Dashboard → Anti-Nuke → Smart Setup, choose a profile and review the changes. Only the owner or an Anti-Nuke Admin can open and apply the preview.
3

Adjust modules and access

Configure thresholds and punishments only where available; review Anti-Nuke Admin, whitelist, and Fake Permissions separately.
4

Test and verify

Keep Monitor and Simulation enabled, then review logs and the resulting status. Switch to Auto only after validating permissions, hierarchy, and response.

​
Troubleshooting and quick answers

Check that Anti-Nuke is enabled, effective mode is Auto, Simulation is off, and the module is enabled. Review Discord permissions, hierarchy, configured punishment, and logs. If the Audit Log cannot reliably attribute the action, Headless avoids punishing an uncertain actor.
No. Anti-Nuke Admin grants configuration access and Administrator is a native Discord permission; neither creates an exemption. Only an explicit whitelist entry exempts a user or bot.

Fake Permissions

Learn which virtual permissions can satisfy supported Headless command checks.

Anti-Raid / Join Gate

Configure join rules and protection against mass joins.

Moderation

Review moderation actions, permissions, cases, and limits.

Content safety

Configure Sentinel filters and distinguish their exemptions from Discord AutoMod.

Headless permissions

See which native and virtual permissions Headless uses.
You can also open the Dashboard to configure the module and review its previews.