# s&box Server Admin Commands & Permission Flags (/docs/sbox/admin-commands)



s\&box has a much smaller console-command surface than Garry's Mod, but what's there is well-defined. This page documents the engine-level permission flags that gate console commands, the API gamemodes use to check claims at runtime, and how the pieces fit together with [`users/config.json`](/docs/sbox/user-permissions). It's a reference, not a step-by-step — for the "give this player kick rights" workflow, see [User Permissions](/docs/sbox/user-permissions).

ConVarFlags — the engine's permission model [#convarflags--the-engines-permission-model]

Every `[ConVar]` and `[ConCmd]` in an s\&box codebase carries a `ConVarFlags` value that describes who can change it and where it runs. The flags below are defined in `Sandbox.ConVarFlags`:

| Flag           | Meaning                                                                                         |
| -------------- | ----------------------------------------------------------------------------------------------- |
| `None`         | No special handling.                                                                            |
| `Saved`        | Value is persisted between sessions.                                                            |
| `Replicated`   | Value is synced from the server to clients. **Only the server or server admins may change it.** |
| `Cheat`        | Cheat command — does nothing unless cheats are enabled.                                         |
| `UserInfo`     | Added to userinfo, accessible via the `Connection` class on other clients.                      |
| `Hidden`       | Hidden from `find` and console autocomplete.                                                    |
| `ChangeNotice` | Notify clients when the value changes.                                                          |
| `Protected`    | Can't be set by game code; only via console or tools.                                           |
| `Server`       | Runs on the server in a multiplayer game.                                                       |
| `Admin`        | **Only an admin of the server can run this.**                                                   |
| `GameSetting`  | Exposed to the platform UI for editing.                                                         |

What this means in practice [#what-this-means-in-practice]

* A command marked `Admin` checks the calling connection's claims before running. Without the right claim, it does nothing.
* A `Replicated` ConVar can be changed at runtime by an admin and will sync to all clients automatically — no manual broadcast needed.
* `Server` commands run on the server even if a client typed them — useful for "kick this player" style actions.
* `Cheat` commands are gated behind whatever the gamemode wires up as its cheat-enable flag. By default they're inert.

You don't author these flags as an operator — gamemode developers do. But knowing they exist tells you why some commands work for you (the host has all claims) but silently no-op for an admin you added.

Connection.HasPermission — the runtime claim check [#connectionhaspermission--the-runtime-claim-check]

When a gamemode wants to check whether a particular player can do something, it calls:

```csharp
Connection.HasPermission( "kick" );
```

The string is whatever claim the gamemode chose. Standard examples are `kick`, `ban`, `restart`. Gamemodes can define their own — `economy.refund`, `world.edit`, anything — and document them in their own readme.

Three things to know about this check:

1. **Server-side only.** Clients cannot reliably check other clients' claims. Don't use this on the client side to decide UI affordances.
2. **The host always returns true.** The dedicated server has every claim implicitly.
3. **Claims are read at connect time**, not per-call. If you edit `users/config.json` while a player is connected, they need to reconnect for the change to apply.

NetPermission — gating networked actions [#netpermission--gating-networked-actions]

Separately from `HasPermission`, the engine has a `NetPermission` enum that controls who is allowed to invoke a networked action (e.g. an `[Rpc]` method):

| Value       | Meaning                                                                                      |
| ----------- | -------------------------------------------------------------------------------------------- |
| `Anyone`    | Anyone can invoke this.                                                                      |
| `HostOnly`  | Only the host (the dedicated server) can invoke this.                                        |
| `OwnerOnly` | Only the owning client can invoke this. For a static action, behaves the same as `HostOnly`. |

Gamemode authors set this on RPCs to stop clients from spam-calling server-only logic. As an operator you don't configure this directly, but it explains why a "give yourself admin" exploit attempt from a client console doesn't usually work — the engine refuses the call before it reaches the gamemode's permission check.

How the layers fit together [#how-the-layers-fit-together]

Three independent layers gate "can this player do this thing":

1. **Engine layer (`NetPermission`)** — can this player even invoke this networked action? Static answer per RPC.
2. **Operator layer (`users/config.json`)** — does this player's SteamID64 have the claim string the gamemode is going to check?
3. **Gamemode layer (`Connection.HasPermission`)** — does the gamemode's code actually call the check at the right moment, with the right claim string?

If any one of these says no, the action is blocked. Most "I added them as admin and they still can't do X" tickets are layer 3 — the gamemode either checks a different claim than you assigned, or doesn't check at all. Look at the gamemode's docs for the exact strings it expects.

Console commands you'll actually use [#console-commands-youll-actually-use]

There isn't a documented public list of admin console commands at the engine level — gamemodes define their own. The panel's **Web Console** is where you'd run them. Common patterns gamemodes implement:

* `kick <name>` — check the gamemode for the exact form.
* `ban <name>` — same.
* `restart` — restarts the round/map.
* `say <message>` — server-side chat.

If a command you expect doesn't exist, it's because the gamemode hasn't implemented it. That's not a server bug — it's a feature gap upstream. File it with the gamemode publisher.

What doesn't exist yet [#what-doesnt-exist-yet]

* **No public RCON.** No external script can run admin commands; use Web Console.
* **No engine-level admin dashboard.** Some gamemodes ship their own; the engine doesn't.
* **No claim discovery API for clients.** A client can't ask "what claims does the server's admin list show?" without the server cooperating.

Related Guides [#related-guides]

* [User Permissions](/docs/sbox/user-permissions) — how to set claims in `users/config.json`.
* [Gamemode vs Operator Config](/docs/sbox/gamemode-vs-operator-config) — what's gamemode-controlled vs operator-controlled.
* [Launch Parameters](/docs/sbox/launch-parameters) — operator-side launch flags.
* [Troubleshooting](/docs/sbox/troubleshooting) — when admins can't perform actions.