---
title: "AMX Mod X Admin Flags (a-z): Full Reference"
excerpt: "The complete AMX Mod X access flag table from a to z, what each flag actually unlocks, common role presets, and how flags map to commands."
category: "administration"
tags: "flags, admin"
image: ""
read_time: "8 min read"
---
<p>AMX Mod X access control is a single string of lowercase letters. Each letter unlocks a category of commands, and a plugin decides which flag its command requires. This is the full <code>a</code>-<code>z</code> reference exactly as the flags are defined in AMXX, plus the role presets most servers actually use. Keep this next to your <a href="/tutorials/users-ini-explained">users.ini</a>.</p>

<h2>1. The complete flag table</h2>
<table>
<thead><tr><th>Flag</th><th>Unlocks</th></tr></thead>
<tbody>
<tr><td><code>a</code></td><td>Immunity — cannot be kicked, banned, slayed or slapped by other admins</td></tr>
<tr><td><code>b</code></td><td>Reservation — can join a full server on a reserved slot</td></tr>
<tr><td><code>c</code></td><td><code>amx_kick</code></td></tr>
<tr><td><code>d</code></td><td><code>amx_ban</code>, <code>amx_banip</code>, <code>amx_unban</code>, <code>amx_addban</code></td></tr>
<tr><td><code>e</code></td><td><code>amx_slay</code>, <code>amx_slap</code></td></tr>
<tr><td><code>f</code></td><td><code>amx_map</code> (change map)</td></tr>
<tr><td><code>g</code></td><td><code>amx_cvar</code> — change server cvars (not all are exposed)</td></tr>
<tr><td><code>h</code></td><td><code>amx_cfg</code> — execute config files</td></tr>
<tr><td><code>i</code></td><td><code>amx_chat</code> and other admin chat commands</td></tr>
<tr><td><code>j</code></td><td><code>amx_vote</code> and vote commands</td></tr>
<tr><td><code>k</code></td><td>Access to the <code>sv_password</code> cvar (through <code>amx_cvar</code>)</td></tr>
<tr><td><code>l</code></td><td><code>amx_rcon</code> and rcon menu access</td></tr>
<tr><td><code>m</code></td><td>Custom level A (for additional plugins)</td></tr>
<tr><td><code>n</code></td><td>Custom level B</td></tr>
<tr><td><code>o</code></td><td>Custom level C</td></tr>
<tr><td><code>p</code></td><td>Custom level D</td></tr>
<tr><td><code>q</code></td><td>Custom level E</td></tr>
<tr><td><code>r</code></td><td>Custom level F</td></tr>
<tr><td><code>s</code></td><td>Custom level G</td></tr>
<tr><td><code>t</code></td><td>Custom level H (commonly used for VIP)</td></tr>
<tr><td><code>u</code></td><td>Menu access (<code>amx_menu</code> and admin menus)</td></tr>
<tr><td><code>z</code></td><td>User — no admin access at all</td></tr>
</tbody>
</table>
<p>There is no <code>v</code>, <code>w</code>, <code>x</code> or <code>y</code> in the standard set. The custom levels <code>m</code>-<code>t</code> are yours: a plugin author picks one and documents it, which is how VIP systems (see <a href="/tutorials/build-vip-plugin">building a VIP plugin</a>) attach to flag <code>t</code>.</p>

<h2>2. How a flag becomes a command</h2>
<p>When a plugin registers a command it names the required flag:</p>
<pre>register_concmd("amx_kick", "cmd_kick", ADMIN_KICK)   // ADMIN_KICK == flag c</pre>
<p>The constants map one to one: <code>ADMIN_IMMUNITY</code> = <code>a</code>, <code>ADMIN_RESERVATION</code> = <code>b</code>, <code>ADMIN_KICK</code> = <code>c</code>, <code>ADMIN_BAN</code> = <code>d</code>, <code>ADMIN_SLAY</code> = <code>e</code>, <code>ADMIN_MAP</code> = <code>f</code>, <code>ADMIN_CVAR</code> = <code>g</code>, up through <code>ADMIN_LEVEL_A</code>-<code>H</code> (<code>m</code>-<code>t</code>), <code>ADMIN_MENU</code> = <code>u</code> and <code>ADMIN_USER</code> = <code>z</code>. So the flags you grant in users.ini line up exactly with the constants plugin authors use.</p>
<p>At runtime a plugin reads a player's flags as a bitmask and tests the one it cares about:</p>
<pre>if (get_user_flags(id) &amp; ADMIN_BAN) {
    // player has flag d
}</pre>
<p>This is why flags stack freely — <code>cdef</code> is just four bits set at once. It is also why a plugin author can convert a string to a mask with <code>read_flags("t")</code> and store it, the approach used when a plugin exposes its own <code>_access</code> cvar so admins can rebind which flag a command needs.</p>

<h2>3. Reading and rebinding a command's flag</h2>
<p>Well-written plugins do not hard-code the flag; they expose a cvar, so you can change the requirement without recompiling. For example a plugin might register <code>amx_slay</code> against a cvar defaulting to <code>e</code>. Check a plugin's <code>.cfg</code> or its documented cvars before assuming a command's flag — two servers can require different flags for the same command name. When in doubt, the AMXX console command <code>amx_help</code> lists the commands available to <em>you</em> given your current flags, which is the quickest way to see the effective mapping on a live server.</p>

<h2>4. Practical role presets</h2>
<ul>
<li><strong>Full admin / owner</strong>: <code>abcdefghijklmnopqrstu</code> — everything except <code>z</code>.</li>
<li><strong>Head admin (no rcon)</strong>: <code>abcdefgijkmnopqrstu</code> — drop <code>l</code> so they cannot run raw rcon.</li>
<li><strong>Moderator</strong>: <code>cdefiju</code> — kick, ban, slay/slap, chat, vote, menu. No immunity, no cvars.</li>
<li><strong>Trial mod</strong>: <code>ceu</code> — kick and slay/slap through the menu only.</li>
<li><strong>VIP</strong>: <code>bt</code> — reserved slot plus custom level H, no admin commands.</li>
<li><strong>Reserved slot only</strong>: <code>b</code>.</li>
</ul>
<p>Give <code>a</code> (immunity) sparingly. An immune troublemaker cannot be removed by your other admins, only by someone with console/rcon.</p>

<h2>Common errors</h2>
<ul>
<li><strong>Granting <code>z</code> and expecting admin power</strong> — <code>z</code> is explicitly "no access". It is used to register a user without privileges, not to grant them.</li>
<li><strong>Forgetting <code>u</code></strong> — an admin with kick/ban flags but no <code>u</code> cannot open <code>amx_menu</code>; they must type commands in console. Add <code>u</code> for anyone who should use the menu.</li>
<li><strong>Confusing flag <code>l</code> with rcon_password</strong> — flag <code>l</code> grants <code>amx_rcon</code> (send commands through AMXX). It is not the engine <code>rcon_password</code>; see <a href="/tutorials/rcon-setup-secure">RCON setup</a>.</li>
<li><strong>Custom-level collision</strong> — two plugins both claiming flag <code>t</code> will both react to it. Check each plugin's docs before reusing <code>m</code>-<code>t</code>.</li>
<li><strong>Immunity abused</strong> — a moderator with <code>a</code> cannot be disciplined by peers. Reserve <code>a</code> for trusted senior staff.</li>
</ul>

<h2>Verification</h2>
<p>Assign a preset in users.ini, run <code>amx_reloadadmins</code>, reconnect, and check <code>amx_who</code> — it lists each online player with their resolved flag string. Then test one command from the granted set and one from a set you deliberately withheld: the withheld command should answer <code>You have no access to that command</code>. That negative test is what proves the flags are doing their job. For placing these flags correctly, return to <a href="/tutorials/users-ini-explained">users.ini explained</a>.</p>