> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mira.party/llms.txt
> Use this file to discover all available pages before exploring further.

# Permissions

> What mira needs, what you need, and how role hierarchy decides the rest.

Three separate things have to line up for a command to work:

1. **You** need the permission the command requires
2. **mira** needs the Discord permission to perform the action
3. **Role hierarchy** has to allow it — for both of you

Most "the bot isn't working" problems are the third one.

## Role hierarchy

Discord will not let anyone — bot or human — manage a member or role that sits **at or above** their own highest role.

```
@Owner          ← can't be touched by anyone
@Admin
@mira           ← mira can manage everything below this line
@Moderator
@Member
@everyone
```

<Warning>
  **Drag mira's role near the top of your role list.** A bot positioned below your staff roles will silently fail to ban moderators, assign senior roles, or revert an antinuke incident involving an admin.

  This is the number one setup problem, and it produces confusing symptoms because *most* things still work.
</Warning>

The same rule applies to you: a moderator can't ban someone whose top role is above their own, regardless of permissions or [fake permissions](/security/fake-permissions).

The **server owner** can never be punished by anyone.

## What mira needs

Administrator covers everything, and is what the invite link asks for. If you'd rather be precise:

| Permission           | Needed for                                       |
| -------------------- | ------------------------------------------------ |
| View Channels        | Everything — logging, snipe, triggers, reposting |
| Send Messages        | Every response                                   |
| Embed Links          | Almost every response                            |
| Attach Files         | Media commands, transcripts, archives            |
| Read Message History | Purge, snipe, starboard, logging                 |
| Add Reactions        | Reaction roles, triggers, starboard, paginators  |
| Manage Messages      | Purge, sticky messages, pinning                  |
| Manage Roles         | Every role feature, mutes, jails                 |
| Manage Channels      | VoiceMaster, tickets, counters, lockdowns, nuke  |
| Manage Webhooks      | Reskin, webhook feeds, snipe relaying            |
| Ban / Kick Members   | Bans, kicks, antinuke, antiraid                  |
| Moderate Members     | Timeouts                                         |
| Manage Nicknames     | Nickname commands                                |
| Manage Expressions   | Emoji and sticker commands                       |
| Manage Threads       | Autothreads, thread commands                     |
| Move Members         | VoiceMaster, `drag`, `moveall`                   |
| Mention Everyone     | Pinging roles from triggers and feeds            |

### Channel overwrites beat role permissions

A role-level allow does **not** override a channel-level deny. If a command works in one channel and not another, check that channel's permission overwrites first — it's almost always the answer.

## What you need

Every command's help page states its requirement:

```javascript theme={null}
!help ban
```

Common ones:

| Permission         | Unlocks                                                       |
| ------------------ | ------------------------------------------------------------- |
| Ban Members        | `ban`, `unban`, `softban`, `tempban`, `hardban`, `massban`    |
| Kick Members       | `kick`                                                        |
| Moderate Members   | `timeout`, `mute`                                             |
| Manage Messages    | `purge`, `warn`, sticky messages, triggers                    |
| Manage Roles       | `role`, `temprole`, `jail`, `lockdown`, reaction/button roles |
| Manage Channels    | `slowmode`, `topic`, VoiceMaster, tickets, counters           |
| Manage Server      | Prefixes, levels, logging, most configuration                 |
| Manage Nicknames   | `nickname`, `forcenickname`                                   |
| Manage Expressions | `emoji`, `sticker`                                            |
| Manage Webhooks    | `webhook`, `reskin`                                           |
| Manage Threads     | `thread`, `autothread`                                        |
| Administrator      | Everything, plus antiraid and honeypot                        |

### Special cases

A few things ignore Discord permissions entirely:

| Feature                                          | Who can use it                             |
| ------------------------------------------------ | ------------------------------------------ |
| [Antinuke](/security/antinuke) settings          | Server owner + explicitly trusted managers |
| [Backups](/setup/backups)                        | Server owner only                          |
| [Tickets](/setup/tickets/overview) configuration | Roles set via `tickets staff`              |
| Minecraft [console](/utility/minecraft#console)  | Minecraft operators, via a linked account  |

Antinuke is deliberately stricter than Administrator — an attacker who gains Administrator would otherwise just turn it off.

## Granting access without Discord permissions

[Fake permissions](/security/fake-permissions) let a role use mira's commands without holding the real permission:

```javascript theme={null}
!fakepermissions grant @Trial Mod ban_members
```

They can now run `!ban` through mira, and nothing else — not Discord's UI, not other bots. Revoking is one command.

Note that mira still performs the action with **its** permissions, and hierarchy still applies to both of you.

## Restricting access further

```javascript theme={null}
!command restrict @DJ play
!module restrict @Staff moderation
!command disable #general ppsize
!ignore @someone
```

See [Command access](/security/command-access).

## Diagnosing a failure

<Steps>
  <Step title="Does the command respond at all?">
    No response usually means the wrong prefix, an [ignored](/security/command-access#ignoring-members-and-channels) member or channel, or a [disabled](/security/command-access#per-command-control) command. Try `@mira ping` to rule out the prefix.
  </Step>

  <Step title="Does it say you lack permission?">
    Check `!help <command>` for what it needs. If you should have it, check the channel's overwrites — a deny there beats your role.
  </Step>

  <Step title="Does it say the bot lacks permission?">
    Check the same overwrites for mira's role, not just its server-level permissions.
  </Step>

  <Step title="Does it fail on one person but work on others?">
    Hierarchy. Their top role is at or above mira's, or above yours. Move mira's role up.
  </Step>

  <Step title="Did it work yesterday and not today?">
    Something moved. A role got repositioned, an overwrite was added, or mira's role was dragged down during a reorganisation.
  </Step>
</Steps>

More in the [FAQ](/reference/faq).