LuckPerms Permission Audit Checklist

Permissions drift over time. Donor ranks gain temporary nodes, old worlds keep contexts, event groups inherit staff powers, and proxy networks split permissions across layers. A safe LuckPerms audit starts with visibility, not mass deletion.

#Export Before Editing

Create a backup or export before changing groups, tracks, contexts, or storage settings. If you run a network, confirm whether LuckPerms storage is shared across proxy and backend servers.

Check these before you touch live groups:

1. Storage backend and connection details.
2. Whether proxy and backend servers share the same storage.
3. Recent changes made through the web editor.
4. Temporary permissions and expiration dates.
5. Rank tracks that control promotion and demotion.

#Review Inheritance From the Default Group Up

Start at the default group and walk upward. Look for abandoned groups, circular inheritance, event ranks, migration leftovers, and groups that inherit more than their name suggests.

The highest-risk pattern is a normal player group inheriting from a staff, admin, or builder group because it was convenient during testing.

#Search for Wildcards

Wildcard nodes can grant entire command families:

essentials.*
worldedit.*
luckperms.*

Keep these limited to trusted admin groups. For player, donor, and helper groups, prefer explicit permission nodes. That makes later audits slower but far safer.

#Check Contexts Before Calling a Permission Broken

Contexts can make the same player behave differently by world, server, region, time, or temporary condition. A permission may be present but scoped to the wrong place.

Review:

1. World contexts for survival, lobby, resource worlds, and minigames.
2. Server contexts on Velocity or BungeeCord networks.
3. Temporary contexts from events or trials.
4. Negated permissions that override inherited grants.

#Use Verbose Logging for One Problem

Verbose logging is best when it is narrow. Test one player, one command, and one expected permission path. If a command fails, verbose output can show the exact node the plugin checked and whether LuckPerms returned true, false, or no value.

After the test, turn verbose logging off. Long verbose sessions create noise and can distract from the actual permission check.

#Audit Proxy Permissions Separately

Proxy commands and backend commands are not the same surface. Velocity or BungeeCord plugins may need permissions on the proxy layer, while Paper plugins need permissions on the backend server.

If a player can run a command in one server but not another, check server contexts, plugin placement, and whether both layers are reading the same LuckPerms storage.

#Confirm Plugin Compatibility Before Blaming LuckPerms

Some permission problems are really plugin version or platform problems. If a plugin changed command names, added a dependency, or moved from Spigot-only to Paper-specific behavior, the node may not be checked the way you expect. Use the plugin conflict auditor and the plugin version mismatch guide before rewriting a stable permissions tree.