Channel Modes

Various modes can be set on channels. Use /mode #channel to list current channel modes and /msg chanserv info #channel to list modes set with MLOCK.

All channel modes will be lost when a channel becomes empty. Enable GUARD to preserve modes.

To set a mode, use /mode #channel +(mode) replacing (mode) with the letter that corresponds to the mode. To unset a mode, use /mode #channel -(mode)

Available channel modes

Mode (name) Description
channel ban

Takes a mask as a parameter. Users matching the mask are prevented from joining or speaking. Sending /mode #channel +b alone will return the current ban list. While in the channel, banned users will be unable to send to the channel or change nick.

You can append $#channel to any ban to redirect banned users to another channel.

For example: /mode #channel +b example!*@*$##fix_your_connection would forward the user with nick example to the channel ##fix_your_connection. /mode #channel +b $~a$#channel-unreg would forward unidentified users to the channel #channel-unreg.

colour filter

Strip colour and formatting codes from channel messages.

block CTCPs

Blocks CTCP commands (other than /me actions).

ban exemption

Takes a mask as a parameter. Ban exemption matches override +b and +q bans for all clients it matches, allowing the exempted user to join/speak as if they were not banned or quieted. This can be useful if it is necessary to ban an entire ISP due to persistent abuse, but some users from that ISP should still be allowed in.

For example: /mode #channel +bee *!*@* *!* $a:JohnDoe would block all users from, while still allowing someuser from host3 and JohnDoe to join.


Takes a channel name as a parameter. Users who cannot join the channel (because of +i, +j, +l, +S, +r, see below) are instead sent to the given channel. Clients are notified when the forward takes effect.

An operator can set /mode +f #channel2 only if they are an op in #channel2 or if #channel2 has mode +F set (see below).

Usually you want to set forwards with MLOCK, because the channel will become empty over time and the channel modes are lost. You might also want to set GUARD to prevent the channel from becoming empty. An operator can use MLOCK with +f only if they have access flag +s in both channels, or if the channel to be forwarded to is +F and they have +s in the original channel.

enable forwarding

Allow operators in other channels to forward clients to this channel, without requiring ops in the target channel.

free invite

Anybody in the channel may invite others (using the /invite command) to the channel.

invite only

Users are unable to join invite-only channels unless they are invited or match a +I entry.

invite exemption

Takes a mask parameter. Matching clients do not need to be invited to join the channel when it is invite-only (+i) or blocking unidentified users (+r). Unlike the /invite command, this does not override +j or +l. Only channel operators can see +I changes or see the list with /mode #channel +I.

Commonly used with the $a extban. /mode #channel +I $a:example would allow a user identified to services as example to enter #channel.

join throttle

This mode takes one parameter of the form n:t, where n and t are positive integers. Only n users may join in each period of t seconds, so with e.g. 3:10 only 3 users could join within 10 seconds. Invited users can join regardless of +j, but are counted as normal. You can use this mode to prevent bot attacks. Observe the average join rate of your channel and pick a good value for +j. This mode could be combined with +f to forward throttled users to an overflow channel.


To enter the channel, you must specify the password on your /join command. Keep in mind that modes locked with ChanServ’s MLOCK command can be seen by anyone recreating the channel; this includes keys. Also keep in mind that users being on the channel when +k is set will see the key as well.

join limit

Takes a positive integer parameter. Limits the number of users who can be in the channel at the same time.


Only opped and voiced users can send to the channel. This mode does not prevent users from changing nicks.

prevent external send

Users outside the channel may not send messages to it. Keep in mind that bans and quiets will not apply to external users.


The KNOCK command cannot be used on the channel, and users will not be shown the channel in whois output unless they share the channel with the requestor. The channel will still appear in channel lists and WHO output (set channel mode +s if this is not desired).


Takes a mask parameter. Works like +b (channel ban), but allows matching users to join the channel.

block forwarded users

Users cannot be forwarded (see +f above) to a channel with +Q.

block unidentified

Prevents users who are not identified to services from joining the channel. Users already in the channel are not affected.

silence unidentified

Prevents users who are not identified to services from sending messages to the channel.


This channel will not appear on channel lists or WHO or WHOIS output unless you are on it.


Only users connected via TLS may join the channel while this mode is set. Users already in the channel are not affected.


Only channel operators may set the channel topic.

block notice

Blocks channel notices (other than CTCP replies, see +C).


Receive messages that are filtered server side by Libera.Chat based on content, usually spam. Set +u if you want the channel to receive these messages. Also see the corresponding user mode.

reduced moderation

The effects of +b, +q, +R, and +m are relaxed. For each message, if that message would normally be blocked by one of these modes, it is instead sent to channel operators (+o).

Restricted channel modes

The following channel modes can only be added by Libera.Chat staff.

Mode (name) Description
large ban list

Increase maximum number of +beIq entries.


Channel does not disappear when empty.


+b, +e, +I, and +q all take a mask to determine which users to match.

The common form of a mask is nick!user@host. The wildcards * and ? are allowed, matching zero-or-more and exactly-one characters, respectively. Bans set on IP addresses will apply even if the affected user joins with a resolved hostname, but will not apply if the user has a cloak. CIDR notation is supported in bans.

The second form, called extbans, can be used for bans based on user data. These entries have the general format $X or $X:data. Optionally, they can be negated with a tilde (~) before the character: for example, $~a matches every user that is not identified to services.

Available extban types

Type (name) Description
account name

Match users identified to the account specified in the parameter. Accepts wildcards; an empty $a matches any logged-in user. For example: /mode #channel +q $a:example would quiet a user identified to services as example.

matching guest

Takes a parameter that is matched as a normal nick!username@host ban (supports CIDR notation) but does not match logged-in users. The parameter accepts wildcards. If the parameter contains a #, the portion after the first # is matched on a client’s gecos, and the portion before the # is matched as a normal ban.

cannot join other channel

Takes an exact channel name (no wildcards or globbing) as its parameter and matches any user who is banned from that channel. Due to caching by the server, a change to the target channel’s ban list may not immediately affect a user’s ability to send to the channel using $j.


Matches on a client’s ircname, or gecos. The parameter accepts wildcards. For example: /mode #channel +b $r:Foo* will ban any user whose gecos begins with “Foo”.

full match

Takes a parameter that is matched on a client’s full nick!username@host#gecos. The parameter accepts wildcards. If the parameter contains a #, the portion after the first # is matched against a client’s gecos, and the portion before the # is matched as a normal nick!username@host ban (supports CIDR notation). For example, /mode #channel +b $x:*#Foo* will ban any user whose gecos begins with “Foo”.

connected securely

Accepts no parameters. Matches users who are connected via SSL/TLS.

Based on content © 2016-2021 freenode/web7.0’s contributors under Creative Commons BY-NC-SA