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

# Fake Permissions

> Fake Permissions assigns virtual capabilities to a role for compatible Headless command checks. It does not change native Discord permissions or make the role a server administrator.

## Who can manage it

Only the server owner or Headless owner can view, grant, revoke, and reset the configuration. Discord administrators and members with virtual permissions are not authorized to manage Fake Permissions. Prefix commands are guild-only.

## Catalog and scope

These keys can be granted: `administrator`, `ban_members`, `mention_everyone`, `kick_members`, `moderate_members`, `manage_guild`, `manage_channels`, `manage_roles`, `view_audit_log`, `manage_webhooks`, `manage_expressions`, `manage_nicknames`, and `manage_messages`. Virtual `administrator` is broad; grant individual permissions when possible. A command's own protection, owner check, role hierarchy, and permissions required by the bot still apply.

### `.fakepermissions list`

```headless-command Syntax theme={null}
.fakepermissions list [role]
```

```headless-command Example theme={null}
.fp list
```

Also works: `.fp list @Moderator`

### `/fakepermissions list`

```headless-command Syntax theme={null}
/fakepermissions list [role:<role>]
```

```headless-command Example theme={null}
/fakepermissions list role:@Moderator
```

## Permission aliases

Input aliases map to catalog keys: `admin` → `administrator`, `ban` → `ban_members`, `kick` → `kick_members`, `timeout` and `mute` → `moderate_members`, `channels` → `manage_channels`, `roles` → `manage_roles`, `messages` → `manage_messages`, `nicknames` → `manage_nicknames`, `server` → `manage_guild`, `webhooks` → `manage_webhooks`, `emojis` → `manage_expressions`, and `audit` → `view_audit_log`. `history` is recognized only to remove the legacy `read_message_history` value; it cannot grant it.

## Configuration and changes

Assignments are persisted by server and role ID in Headless configuration. You can enter multiple keys separated by spaces or commas; Headless normalizes aliases, removes duplicates, and rejects the operation if any key is unknown. Do not use `@everyone` or integration-managed roles. List all assignments or inspect one role.

### `.fakepermissions add`

```headless-command Syntax theme={null}
.fakepermissions add <role> <permissions>
```

```headless-command Example theme={null}
.fp add @Moderator manage_messages, kick_members
```

Also works: `.fp grant @Moderator manage_messages`

### `.fakepermissions remove`

```headless-command Syntax theme={null}
.fakepermissions remove <role> <permissions>
```

```headless-command Example theme={null}
.fp remove @Moderator manage_messages
```

## Legacy permissions

`read_message_history` is no longer assignable. If an older configuration already contains it, Headless preserves it rather than silently removing existing behavior; use `remove` to clear it. It cannot be granted again.

### `/fakepermissions grant`

```headless-command Syntax theme={null}
/fakepermissions grant role:<role> permissions:<permissions>
```

```headless-command Example theme={null}
/fakepermissions grant role:@Moderator permissions:manage_messages
```

### `/fakepermissions revoke`

```headless-command Syntax theme={null}
/fakepermissions revoke role:<role> permissions:<permissions>
```

```headless-command Example theme={null}
/fakepermissions revoke role:@Moderator permissions:manage_messages
```

## Protected reset

`.fp reset` displays a confirmation that expires after 90 seconds. Only the requester can confirm it, in the same server, and Headless checks that they are still an authorized owner. Confirming removes every virtual assignment in that server; canceling or letting the prompt expire leaves the configuration unchanged.

### `.fakepermissions reset`

```headless-command Syntax theme={null}
.fakepermissions reset
```

```headless-command Example theme={null}
.fp reset
```

### `/fakepermissions reset`

```headless-command Syntax theme={null}
/fakepermissions reset
```

```headless-command Example theme={null}
/fakepermissions reset
```

> [!NOTE]
>
> This does not grant native Discord permissions, Anti-Nuke configuration access, or an Anti-Nuke whitelist exemption. Virtual `administrator` is still limited to compatible Headless checks and does not replace a command's own access controls.

**Note:**

Prefix commands reply in the channel where they run; slash responses are private. Grants and revocations are recorded in Headless system logs.

## Steps

**1. Choose a regular role**

Create or select a manageable staff role; do not use `@everyone` or a role managed by an integration.

**2. Grant the minimum needed**

Add only the capabilities a compatible Headless command requires. For example, `manage_messages` and `kick_members` are independent entries.

**3. Review the scope**

Use `.fp list` or inspect one role, and make sure this grant is not confused with the Anti-Nuke whitelist or Anti-Nuke administrators.

**4. Test the protected command**

Run an allowed action in a test context. A virtual capability does not grant the Discord permissions the bot itself needs to perform the action.

## Related pages

* [Headless permissions](/docs/en/permissions.md)
* [Anti-Nuke](/docs/en/security/anti-nuke.md)
* [Moderation](/docs/en/security/moderation.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.