Oxide Commands List: Console Commands for Plugins, Permissions and Groups

Oxide console commands all begin with oxide. and are typed into the server console, RCON or the in-game F1 console as an admin. They cover three jobs: managing plugins (oxide.plugins, oxide.load, oxide.unload, oxide.reload), managing permissions (oxide.grant, oxide.revoke, oxide.group, oxide.usergroup) and inspecting state (oxide.show, oxide.version). Carbon accepts the same oxide.* commands.

Arguments in <angle brackets> are required, [square brackets] are optional. Player arguments accept a name or a 17-digit Steam ID. Use the ID when names contain spaces or could match several players.

Plugin management commands

<Name> is the plugin name, which matches the file name and class name (for example StarterKit), not the readable title. The * wildcard applies the action to everything.

Example:

oxide.reload StarterKit

On success the console prints lines such as Unloaded plugin Starter Kit v1.0.0 by RustPluginGenerator followed by Loaded plugin Starter Kit v1.0.0 by RustPluginGenerator. There is no separate "compiled successfully" message. If the file fails to compile, the console prints Error while compiling StarterKit: and numbered messages in the form [1] <message> at <line>:<column>. The broken plugin is skipped and the others keep running. See CS0103 or CS1002 for typical causes, and could not load plugin, no plugin found when the name does not match a file.

Saving a .cs file in oxide/plugins already triggers a reload on its own, so you rarely need oxide.reload for code changes. It is useful after editing a config in oxide/config or a data file in oxide/data by hand. A reload runs Unload, then Init and Loaded. On a running server, OnServerInitialized is called right away with false.

oxide.plugins is also the quickest performance check. Slow hooks are logged as Calling 'OnEntityTakeDamage' on 'Name v1.0.0' took 120ms; see took ms hook performance warning and the performance guide.

Permission commands

Examples:

oxide.grant user 76561198000000000 starterkit.use
oxide.grant group default starterkit.use
oxide.revoke user Steve starterkit.use

Permission names follow <pluginname>.<action>, in lowercase. A permission can only be granted once its plugin has registered it, so load the plugin first. If you get "permission doesn't exist", read permission doesn't exist. A permission granted to default applies to every player. Lookups are case-insensitive. Oxide may also call OnUserPermissionGranted when a user receives a permission.

Group commands

Oxide ships with the groups default and admin. Players join default automatically.

oxide.group add vip "VIP" 1
oxide.group parent vip default
oxide.grant group vip starterkit.vip

A child group inherits everything its parent has. Giving vip the parent default means VIPs keep all default permissions and add their own. Referencing a group that was never created produces group doesn't exist. The full model is explained in Oxide permissions and groups.

Usergroup commands

oxide.usergroup add 76561198000000000 vip
oxide.usergroup remove 76561198000000000 vip

Group membership is the right tool for tiers such as VIP, because you grant a permission once to the group and change only membership per player. A plugin can do the same automatically, as in Playtime group promotion.

Inspection commands

oxide.show perm starterkit.use
oxide.show user 76561198000000000

Use oxide.show user first when a player reports they cannot use a command. It shows direct permissions and the groups they inherit from, which settles most access questions.

Language and version commands

oxide.lang de

Plugins that register translations with lang.RegisterMessages read the language chosen here, falling back to English if a key is missing. Message files are stored in oxide/lang/<lang>/<Name>.json. See plugin localization.

Run oxide.version first when asking for help or after a game update. Version mismatches are the usual reason plugins stop working, as covered in fix Rust plugins after an update.

Where the files live

Carbon equivalents

Carbon loads Oxide plugins and accepts the oxide.* commands listed above, so existing scripts, RCON tools and documentation keep working. Carbon also has its own command set under the c. prefix (for example c.reload and c.grant) with the same purpose. Check the Carbon documentation for exact syntax on your build. For the differences between the two frameworks see Oxide vs Carbon.

Running commands safely

• Test oxide.unload * and oxide.reload * off-peak. Reloading everything resets plugin state held in memory and can cause lag while many plugins recompile.
• Prefer targeted reloads: oxide.reload <Name>.
• Put repeated setup in a startup script or use Scheduled commands for timed actions.
• Plugin-defined console commands such as myplugin.give are separate from the oxide.* set. The difference from chat commands is covered in chat commands vs console commands.

If a command prints nothing useful, check oxide/logs and read debugging Rust plugins.