How to Enable Command Blocks on a Minecraft Server

Command blocks are off by default, so to use them on a server you set enable-command-block=true in server.properties, restart the server so the change takes hold, then give yourself one with /give because there's no crafting recipe for it. That's really all of it, and from there the only thing that matters is who's allowed to place and edit them, and keeping that list short. None of this depends on your server software, since command blocks are a vanilla Minecraft feature that Paper, Spigot, and Fabric all respect, so the steps read the same on a Paper setup or plain vanilla.

Set enable-command-block=true in server.properties

The setting lives in server.properties, the same file you tune for things like view distance and the default gamemode, and it ships as enable-command-block=false. Open the file, find that line, and change false to true. While it's false, nobody can program or run command blocks — a player can't open the editing screen, and even a block already sitting in the world does nothing when it's triggered, so an old map full of command blocks will look broken until you flip this.

Stop the server before you touch the file. If you edit server.properties while the server is running, it'll overwrite your change the next time it saves its own copy, and the value wouldn't have applied mid-session anyway. On a managed host you usually won't be editing raw text at all — the control panel exposes this as a toggle or a field in its config editor — but it writes the exact same property behind the scenes.

Restart to apply — a reload won't do it

server.properties is read once, when the server boots, so your new value only counts after a full restart: stop the server, then start it again. There's a trap here for owners who already know /reload from working with datapacks. /reload re-reads your datapacks and functions, and it's genuinely handy for that, but it does not re-read server.properties. Run /reload after changing enable-command-block and the setting still won't apply — the file only gets read at startup. If you've spent time installing datapacks, you've probably leaned on /reload a lot, so it's an easy reflex to misapply here. Stop and start, and the setting takes.

Get a command block: use /give, it isn't craftable

There's no crafting recipe for a command block, and that's deliberate — it's an operator-only block, so the only way to get one is a command. From the server console, run /give <player> command_block, swapping in a real player name; the console can't use @s, and @p works too if someone's nearby. In-game, an op runs /give @s minecraft:command_block and the block lands in their inventory.

A couple of other routes do the same thing. /setblock ~ ~ ~ command_block drops one right where you're standing instead of into your inventory. And in Creative mode the block shows up under the Operator Utilities tab of the inventory, as long as the Operator Items Tab control is switched on, so you can pull it from there or pick-block one that's already placed. All of these need operator permission to run, which is the thread running through the rest of this.

Place and edit one: operator plus Creative mode

To place a command block and open its editing screen, a player has to be both an operator and in Creative mode. Neither one on its own is enough — an op who's still in Survival can't open the GUI at all.

On Java this hangs on op-permission-level. Editing a command block needs level 2 or higher, and the default op-permission-level is 4, so a normal op already clears the bar. The only way you'd hit a wall is if you've deliberately lowered someone below 2. Worth knowing if your ops can't edit blocks they expect to: check that number before you go hunting for a bigger problem.

Players in Survival, and ops who simply aren't in Creative, can't place or edit blocks — but blocks that are already placed still fire for them. That's the whole point of a teleport pad or a bit of lobby logic: a normal player walks over the trigger and it works, without them needing op or Creative at all. Inside the GUI you've got the command line along the bottom, plus the type and activation toggles worth understanding before you build anything real.

The three types and how they activate

A command block comes in three flavors, and you cycle between them with a button in the GUI. Impulse is the orange one and it's the default — it runs its command once each time it gets powered. Repeating is purple and runs its command every game tick while it's active, which is how you'd poll for a player standing in a region. Chain is green and runs the instant the block pointing into it succeeds, so you string several together to fire commands in a set order within a single tick.

Then there's how the block decides to run at all. Needs Redstone means it only fires when it gets a signal — a lever, a button, a pressure plate, a redstone block, whatever you wire to it. Always Active means it runs on its own with no signal needed, which is what you almost always want on a Repeating block. Chain blocks add one more toggle, Conditional versus Unconditional, which controls whether the block waits for the previous one in the chain to succeed before it runs.

One gamerule shapes how chains behave: maxCommandChainLength caps how many chained blocks run per tick. The default is high enough that you'll rarely hit it, but if someone's set it to 0 your chains just won't run, which is the kind of thing that sends you debugging the wrong block for an hour.

What server owners actually build with them

Most of what command blocks are good for is small, in-world automation. Teleport pads and lobby spawns, setting a player's gamemode or handing them effects when they cross into an area, scoreboard and minigame logic, timed broadcasts to the whole server, a /give block that kits players out when they start. They're the backbone of vanilla minigame and adventure maps — if you've played a custom map where the floor drops out or your inventory fills on spawn, that was command blocks doing the work, and you'll see those systems running live across the minigames servers.

Where they stop being the right tool is scale. Once you're maintaining the same logic server-wide, a datapack of functions is far easier to live with than walls of blocks scattered through the world, because the functions are plain files you can read, back up, and edit outside the game. And for jobs command blocks handle badly — permissions, rank systems, anything that needs to survive a world reset cleanly — a plugin is the better fit. Command blocks are great for the handful of bespoke things a map needs; they're a poor database.

Lock down who can use them

Here's the part that bites people on public servers: a command block runs its command at permission level 2 no matter who or what set it off. The block carries the elevated rights, not the person. So a pressure plate wired to a command block executes that command with op-level power even when a regular, non-op player is the one standing on it.

That's fine when the command is a teleport. It's a real problem when the command ops players, switches gamemodes, hands out items, or teleports people somewhere they shouldn't be — because anyone who can trip the redstone effectively runs it. The actual control, then, isn't the block. It's who you give op to and who you let into Creative, since those are the only two things that let someone place a dangerous block in the first place. Keep the op list short and look it over now and then, keep ordinary players out of Creative, and use a permissions plugin like LuckPerms when you need finer control than vanilla op gives you.

A bit of practical hygiene goes a long way too. /gamerule commandBlockOutput false stops a Repeating block from filling your admin chat with output every single tick — it's a visibility setting, nothing more, but you'll want it off once you've got Always Active blocks running. And before you open a world to the public, walk the command blocks that are already in it and confirm none of them quietly do something a player could trigger on purpose. One Always Active block in the wrong spot can undo your moderation without anyone noticing for a while.

FAQ

My Repeating command block does nothing until I change a setting — which one?

A freshly placed command block defaults to Needs Redstone, and on a Repeating block that means it just sits there until it gets a signal. Flip it to Always Active and it starts ticking on its own. The reason this catches people is that they expect Repeating to start the moment they close the editor, so they go back and re-check the command itself when the command was never the issue — the activation toggle was. If a Repeating block is genuinely meant to fire only sometimes, leave it on Needs Redstone and wire a signal to it instead.

Does the /give command need the minecraft: prefix?

On any current version, /give @s command_block and /give @s minecraft:command_block both work, because the game assumes the minecraft: namespace when you leave it off. The prefix only earns its keep when a datapack or mod has registered something else under the same short name, which is uncommon. If you're following an old tutorial on a much older version, note that the /give argument order and item IDs shifted over the years; the modern form is a player target first, then the item ID, then an optional count.

Why can't I break a placed command block, even as an operator?

Command blocks can't be mined in Survival at all, and they shrug off explosions, which is intentional so a creeper or a passing player can't wipe out your logic. Removing one needs the same state as placing one: Creative mode plus op. If you're an op standing in Survival in front of a block you can't dent, swap to Creative and it'll break instantly like anything else. That unbreakability is also why a buried command block someone forgot about can keep running long after the build around it is gone.