Player Delegate

Player Delegate lets console initiate prompts for one target player, then dispatches the completed command as that player with a temporary permission group.

/playerdelegate <target> <permission-key> <command...>
/pd <target> <permission-key> <command...>

• target accepts a player name or a single-target selector such as @p. Multi-target selectors such as @a are rejected by the command's singular player argument.

• permission-key must match a group under Permission-Attachment.Permissions. Tab completion suggests only actually configured permission group keys.

• %target_player% is replaced with each target's name.

• The sender must be console and have promptpaper.playerdelegate.

When Enable-Permission is enabled and the delegated command contains prompt tags, the target player must also have promptpaper.use. The temporary attachment is applied only at final dispatch, so it cannot supply this initial gate. This target-side check does not block a direct delegated string with no prompt tags.

/playerdelegate CyR1en GAMEMODE gamemode <Which gamemode?> %target_player%

The configured permissions are attached immediately before dispatch and removed after Permission-Attachment.ticks (defaults to 0 in 3.2.0). If command dispatch fails or throws, the attachment is removed immediately. An unknown or empty permission group is rejected.

If the delegated string contains no prompt tags, it is dispatched immediately as the target player with the configured attachment. An unresolved preset or another rejected tag form is not dispatched literally.

Unqualified inline post-commands inherit the player execution context and the same permission-attachment behavior. An explicit @player forces player execution but does not inherit the attachment. A preset post-command follows its own execute_as setting and never inherits the delegate attachment, even when execute_as is player.

See Permission Attachment for configuration and security guidance.