Skip to main content

​
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

Also works: .fp list @Moderator

​
/fakepermissions list

​
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

Also works: .fp grant @Moderator manage_messages

​
.fakepermissions remove

​
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

​
/fakepermissions revoke

​
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

​
/fakepermissions reset

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.