Permission Attachment

Permission attachments temporarily grant a target player a named set of permissions while Player Delegate dispatches a command.

Permission-Attachment:
  ticks: 1
  Permissions:
    GAMEMODE:
      - bukkit.command.gamemode
      - essentials.gamemode.survival
      - essentials.gamemode.creative

Use the group name as the delegate's second argument:

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

CommandPrompter captures the configured permission list for the delegated main command, unqualified inline post-commands that inherit the delegate context (on completion or cancellation), and direct no-prompt dispatch. It attaches the permissions immediately before each applicable player dispatch and schedules removal after ticks when that value is positive. 0 or a negative value removes the attachment immediately after dispatch. A thrown dispatch error or removal-scheduling failure also triggers immediate removal. If Bukkit merely returns false from dispatch, 3.1.1 reports the failure but retains the attachment until its normal configured removal.

Delayed inline post-commands that inherit a Player Delegate context verify that the named group still exists and has the same permissions before attaching it. If the group changed, the delayed command is skipped. An explicitly marked @player post-command does not inherit the attachment.

Preset post-commands never inherit the Player Delegate attachment, including presets configured with execute_as: "player"; their executor is authoritative but their dispatch context is independent.

The target can use attached permissions during the configured retention window, not only inside the delegated command call. Keep ticks as low as practical and never grant broad administrative permissions.