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

# Command access

> Decide which commands work where, and who can run them, with rules for a channel, a category, or the whole server.

Command policies control where Bloom's commands work and who can use them. A rule says allow or deny, names what it applies to, and names where it applies. You can turn one command off in one channel, restrict a whole category to a role, or shut everything down outside a bot channel.

<Info>
  Every command here needs **Administrator**.
</Info>

## How a rule is decided

When someone runs a command, Bloom checks the rules in this order:

<Steps>
  <Step title="Protected commands always run">
    A short list of commands can never be blocked, so a bad rule cannot lock you out of fixing it.
  </Step>

  <Step title="Administrators always pass">
    Policies never apply to administrators or the server owner. Test your rules with an ordinary account.
  </Step>

  <Step title="The most specific rule wins">
    Bloom scores every rule that matches and applies the narrowest one.
  </Step>

  <Step title="A tie goes to deny">
    When two equally specific rules disagree, the denial wins.
  </Step>
</Steps>

Specificity is decided by **where** the rule applies before anything else:

| Most specific |                             |              | Least specific   |
| ------------- | --------------------------- | ------------ | ---------------- |
| This channel  | The thread's parent channel | The category | The whole server |

A channel rule always beats a server rule, whatever else the two rules say. Within the same place, a rule naming one command beats a rule naming a category of commands, which beats a rule naming everything. A rule for a role beats a rule for everyone.

<Info>
  This means the usual pattern works the way you would hope: deny everything server wide, then allow what you want in the channels where you want it.
</Info>

## Commands that cannot be blocked

`commandpolicy`, `disablecommand`, `enablecommand`, `restrictcommand`, `unrestrictcommand`, their short aliases, plus `setprefix` and `help`.

<Tip>
  This is your way back. If a rule locks a channel down harder than you meant, `!commandpolicy rules` and `!commandpolicy reset` still work there.
</Tip>

## Setting rules

<ParamField path="commandpolicy deny <all|command|category:name> [#channel] [@role]" type="Administrator">
  Blocks something. Aliases: `cmdpolicy`, `cmdrules`.

  * Without a channel the rule covers the whole server.
  * Without a role the rule covers everyone.
  * `!commandpolicy deny all #general` turns every command off in one channel.
  * `!commandpolicy deny category:fun` turns off a whole category server wide.
</ParamField>

<ParamField path="commandpolicy allow <all|command|category:name> [#channel] [@role]" type="Administrator">
  Permits something, overriding a broader denial.

  * `!commandpolicy allow ping #general` re-enables one command in a channel you had closed off.
</ParamField>

<ParamField path="commandpolicy restrict <all|command|category:name> <@role> [#channel]" type="Administrator">
  Limits something to one or more roles in a single step. Bloom writes a denial for everyone and an allowance for each role you name, replacing any existing rules for that target.

  * At least one role is required.
  * `!commandpolicy restrict category:music @DJ #music` leaves music commands working only for DJs, only in that channel.
</ParamField>

## Checking and undoing rules

<ParamField path="commandpolicy rules [#channel]" type="Administrator">
  Lists your rules, each with an ID. With a channel it shows only the rules that affect that channel. Alias: `list`.
</ParamField>

<ParamField path="commandpolicy status [#channel]" type="Administrator">
  Reports how many rules affect a channel, as a quick check before you add another.
</ParamField>

<ParamField path="commandpolicy test <command> [#channel] [@role]" type="Administrator">
  Answers whether a command would run, for the channel and roles you name, and shows which rule decided it. Use it instead of guessing.

  * `!commandpolicy test ping #general` explains the outcome for that combination.
</ParamField>

<ParamField path="commandpolicy reset <rule_id|server|#channel>" type="Administrator">
  Removes rules. Aliases: `remove`, `delete`. Takes a single rule ID from `commandpolicy rules`, or clears everything at one scope.
</ParamField>

<ParamField path="commandpolicy catalog" type="Administrator">
  Lists every command category with how many commands it holds, which is how you find the right name for `category:`.
</ParamField>

## Shorter commands for common cases

These are shortcuts into the same system. A rule made with `disablecommand` is an ordinary policy rule, and shows up in `commandpolicy rules` like any other.

| Shortcut                              | Same as                                    |
| ------------------------------------- | ------------------------------------------ |
| `disablecommand <command> [#channel]` | `commandpolicy deny <command> [#channel]`  |
| `restrictcommand <command> <@role>`   | `commandpolicy restrict <command> <@role>` |
| `enablecommand list`                  | `commandpolicy rules`                      |
| `unrestrictcommand <command>`         | Clears that command's restriction          |

<ParamField path="disablecommand <command|list> [#channel]" type="Administrator">
  Turns a command off, in one channel or across the server. Aliases: `dcmd`, `disablecmd`.
</ParamField>

<ParamField path="restrictcommand <command|list> [role]" type="Administrator">
  Limits a command to a role. Aliases: `restrictcmd`, `rcmd`.
</ParamField>

## Worked example

To make a bot channel the only place general commands work, while leaving moderators unrestricted everywhere:

```text Lock commands to one channel theme={null}
!commandpolicy deny all
!commandpolicy allow all #bot-commands
!commandpolicy allow all @Moderator
```

The first rule closes the server. The second beats it in `#bot-commands` because a channel rule outranks a server rule. The third beats it for moderators because a role rule outranks an everyone rule at the same scope. Confirm it with `!commandpolicy test ping #general` before you walk away.

## Troubleshooting

<AccordionGroup>
  <Accordion title="My rule does nothing for me but works for others">
    Administrators and the server owner bypass every policy. Test with an account that holds no administrator permission.
  </Accordion>

  <Accordion title="A command is still blocked after I allowed it">
    A more specific rule is winning. Run `!commandpolicy test <command> #channel` to see which rule decided the outcome, then narrow your allow rule to match or remove the rule that is beating it.
  </Accordion>

  <Accordion title="Two rules contradict each other">
    When two rules are equally specific, the denial wins. Make the allowing rule more specific, for example by naming the channel or the role rather than the whole server.
  </Accordion>

  <Accordion title="Cannot disable that command">
    It is on the protected list, which exists so a rule cannot lock you out of the commands that fix rules.
  </Accordion>

  <Accordion title="Command was not found">
    Use the exact command name rather than an alias, and `!commandpolicy catalog` for the category names that `category:` accepts.
  </Accordion>

  <Accordion title="I locked myself out of a channel">
    The policy commands still work everywhere. Run `!commandpolicy reset #channel` in the affected channel, or `!commandpolicy reset server` to clear the server wide rules.
  </Accordion>
</AccordionGroup>

## Related pages

<CardGroup cols={2}>
  <Card title="Fake permissions" icon="user-shield" href="/security/fake-permissions">
    Granting access to commands rather than taking it away.
  </Card>

  <Card title="Permissions and hierarchy" icon="user-lock" href="/getting-started/permissions">
    The permission checks that run after a policy allows a command.
  </Card>

  <Card title="Commands not responding" icon="circle-question" href="/troubleshooting/commands">
    Working out whether a policy is why nothing happened.
  </Card>

  <Card title="Command aliases" icon="wand-magic-sparkles" href="/configuration/aliases">
    Custom names for commands, which policies apply to as well.
  </Card>
</CardGroup>