/mod unwarn

Revoke a matching active warning for a member.

Availability

Public source-edition command; execution remains conditional on installation, server policy and the running service. This reference is built from the repository, not a live Discord registration probe. Explicit registration contexts: server.

Syntax

/mod unwarn <user:User> [warn_id:Integer] [reason:String]

Angle brackets indicate required input; square brackets indicate optional input. In Discord, choose the command and fill its named options, rather than typing the brackets.

Parameters

Name	Type	Required	Allowed values / bounds	Default when omitted	Description
`user`	User	Yes	No registration choices declared; handler validation applies.	Required input	Target member to unwarn
`warn_id`	Integer	No	No registration choices declared; handler validation applies.	Most recent active warning.	Specific warning ID to clear (leave empty to clear most recent)
`reason`	String	No	No registration choices declared; handler validation applies.	Warning revoked by moderator.	Reason for revoking warning

Permissions

Required native member permission(s): ModerateMembers (Administrator normally satisfies native permission checks).

Fork role access is evaluated using the underlying unwarn policy key, even when the slash name is grouped. Native Discord permission checks remain separate from Fork role grants. Sensitive commands fail closed before valid setup; native Administrator bypasses Fork’s role matrix, not Discord’s bot permissions or target hierarchy. See Permission model.

Where a member-targeting mutation calls the hierarchy guard, the server owner, the caller and Fork are protected. Targets must be below the acting moderator (except the owner) and Fork. Read-only history/list paths do not necessarily apply the same target guard. The bot needs the native permission required by the actual Discord action.

Examples

/mod unwarn user:@Alex warn_id:42 reason:Appeal accepted

Prefix equivalent and aliases

f!unwarn @Alex 42 Appeal accepted

Default prefix: f!; installations can configure another. Handler aliases: clearwarn, clearwarns, delwarn. Aliases are prefix names, not additional slash commands. Handler-declared usage: f!unwarn @user [warn_id] [reason].

Grouped prefix routes also delegate to the original handlers, but aliases retain that handler’s argument parsing. Conflicting aliases are rejected as ambiguous. Prefix replies are generally visible in the channel; prefer slash privacy controls for sensitive personal data.

Expected result

Clears the requested warning, or the most recent when no ID is supplied; reports remaining count. No match is not reported as a change.

Failure cases

Wrong server/user ID, already-cleared warning, hierarchy restrictions or storage failure may leave nothing changed. Check the returned error, current bot status and the relevant server permissions. A timeout or uncertain receipt is not proof that nothing happened; inspect state before repeating a mutation.

Usage limits

No fixed command-specific cooldown is declared in this reviewed entry. Discord rate limits, provider budgets, service admission and server policy can still apply; this is not an unlimited-usage promise.

Source edition v1 · Registration, direct handler and shared authorization review are hash-bound in the local documentation validation. This is not a production feature-availability certification.