Chapter 4 — The /execute Command

What You’ll Build

This is the most important command in Minecraft, and it’s the one that turns a list of commands into something that can actually think. So far, every command you’ve written runs as you, where you are, no matter what. /execute breaks all three of those rules. It lets you run a command as a different entity, run it at a different place, and run it only if something is true. By the end of this chapter you’ll be able to read a long /execute line left to right and say exactly what each piece does, and you’ll have typed two real /execute commands into the chat box: one that gives a player a potion effect while they stand on a gold block, and one that calls down lightning on every zombie at once. These two small lines use the same machinery that powers nearly every advanced data pack ever made.

This chapter assumes you’re comfortable with target selectors from Chapter 3 (@s, @e, @a, and filters like type= and distance=) and with coordinates from Chapter 2 (absolute, ~ relative, ^ local).

Why /execute exists

Every command secretly carries some hidden background information with it: who is running it, and where it’s running. The official description of the command says it plainly: /execute “executes another command but allows changing the executor, changing the position and angle it is executed at, adding preconditions, and storing its result.” Read that again, because the whole chapter is just those four powers spelled out:

• change the executor: run a command as a different entity (this changes what @s means).
• change the position: run a command at or positioned at a different place (this changes what ~ ~ ~ means).
• add preconditions: run the command only if (or unless) some condition is true.
• store its result: save a number the command produces (you’ll preview this here; the details come later).

Two pieces of vocabulary make the rest of the chapter easy. The executor is the entity a command runs as. It’s what @s (“self”) points at. The execution position is the point a command runs at, the spot relative coordinates like ~ ~ ~ are measured from. Plain commands always use you as the executor and your spot as the position. /execute is how you change either one.

A piece of /execute is called a subcommand (the game also calls them instructions). You chain subcommands together, and the very last one is always run, followed by the real command you want to carry out. Here’s the shape of every /execute line you’ll ever write:

/execute <subcommand> <subcommand> ... run <the actual command>

The subcommands fall into a few jobs: modifier subcommands change the context (who and where), condition subcommands test something (if/unless), a store subcommand saves a result, and the run subcommand carries out the real command at the end. We’ll meet one job at a time.

Modern Minecraft Older tutorials sometimes show a chat command typed straight into the box, like /execute @e ~ ~ ~ summon lightning_bolt. That old grammar was retired years ago. Current Java Edition uses the named-subcommand form you’re learning here (execute as @e at @s run summon lightning_bolt), which reads almost like a sentence. If a tutorial’s /execute looks like a string of bare selectors and coordinates with no words like as, at, or run, it’s out of date.

as — change who runs the command (the executor)

The as subcommand “sets the executor to target entity.” In plain terms: it changes who the command thinks it is, which changes what @s means. Its syntax is:

as <targets> -> execute

That little -> execute is shorthand for “another subcommand must follow”: as can’t be the end of the line. Here’s the classic example:

/execute as @e[type=sheep] run kill @s

Walk through it: as @e[type=sheep] makes the game pretend, one at a time, that it is each sheep. Then run kill @s kills “self,” and because “self” is now a sheep, every sheep dies. Without execute as, kill @s would just kill whoever typed the command.

This reveals something important. When a selector picks more than one entity, the rest of the chain runs once for each one. This is called forking into multiple branches: when the as subcommand selects multiple entities, the subcommands following it execute once per entity. This is how one line of /execute can act on a hundred mobs: you type the command once, and the fork runs it for each match.

at — change where the command runs (the position)

The as subcommand changes who, but, importantly, it does not change where. There’s an important detail here: as sets the executor without changing the execution position. So if you do execute as @e[type=sheep] run particle ..., every sheep is the executor, but the particle still appears at your feet, because the position never moved.

That’s what at is for. The at subcommand “sets the execution position, rotation, and dimension to match those of an entity.” Its syntax:

at <targets> -> execute

The two are almost always used together as as @e[...] at @s, which reads: “for each matching entity, become it (as), then move to its spot (at @s).” This example makes the pairing clear:

/execute as @e[type=sheep] at @s run tp @s ~ ~1 ~

This moves every sheep up one block. as @s makes each sheep the executor, at @s moves the position to that sheep, and tp @s ~ ~1 ~ teleports self one block above its current spot.

To see why order matters, compare these two lines:

• /execute as @e at @s run tp ^ ^ ^1: all entities move one block forward.
• /execute at @s as @e run tp ^ ^ ^1: all entities teleport to one block in front of the executor.

The game reads subcommands strictly left to right, so swapping as and at gives two completely different results. There’s also a trap worth memorizing: at never changes who the executor is. Watch this gotcha. /execute at @e[type=sheep] run kill @s kills the player running the command, because at does not change the executor. You moved the position to a sheep, but @s is still you.

positioned — set the position directly

at borrows a position from an entity. positioned lets you set the position yourself, with no entity needed: it sets the execution position directly. It has a few forms; the two you’ll use are:

positioned <pos> -> execute
positioned as <targets> -> execute

positioned <pos> takes coordinates, like positioned 0 64 0. This example searches for a village near a fixed point:

/execute positioned 0 64 0 run locate structure #village

positioned as @s, on the other hand, copies an entity’s position only. Unlike at, it leaves the rotation and dimension alone. For most beginner uses, at @s is what you want; reach for positioned when you need an exact coordinate or you only want the location, not the facing.

if / unless — run the command only when something is true

So far we can change who and where. The condition subcommands add whether. The if and unless subcommands restrict command execution to happen only under specified conditions. In most cases, unless is a negation of if, equivalent to “if not…”. When a condition fails, that branch simply stops (it “terminates”) and the run never happens.

if and unless come in several flavors. The two you’ll use constantly are if entity and if block.

if entity checks whether a matching entity exists. Syntax:

(if|unless) entity <entities> -> [execute]

The [execute] in brackets means another subcommand here is optional: if can be the last thing on the line, or it can be followed by run. So /execute if entity @e[type=creeper,distance=..10] run say A creeper is near! only says the message when a creeper is within 10 blocks.

if block “compares the block at a given position to a given block ID or a block tag.” Syntax:

(if|unless) block <pos> <block> -> [execute]

This is how you check what someone is standing on. This example kills any player standing on a wool block:

/execute as @a at @s if block ~ ~-1 ~ #wool run kill @s

Read it as a sentence: for each player (as @a), at their position (at @s), if the block one below them (~ ~-1 ~) is wool, kill them. The ~ ~-1 ~ means “same X and Z, one block down,” exactly the spot your feet rest on. You’ll reuse this exact pattern in the practice below, swapping wool for gold.

There are more condition types you’ll meet in later chapters. Three are worth naming now so the syntax doesn’t surprise you when an online tutorial uses it:

• if score compares scoreboard numbers, e.g. if score @s wins matches 3... Scoreboards are a whole system of their own. You’ll learn them in Chapter 11, and if score with them.
• if predicate checks a named, reusable condition you save as a JSON file. Predicates get their own Chapter 18.
• if data checks whether an entity or block has a piece of data; the data system (command storage) is Chapter 12.

Try It! unless is just if flipped. Once you’ve typed the gold-block command below, try changing if block to unless block and stand off the gold — the effect now applies everywhere except on gold. Reading unless as “if not” makes these lines click.

store — saving a result (preview)

The fourth power, store, stores the final subcommand’s result or success value somewhere. A command quietly produces a number when it runs (for example, if entity @e[type=zombie] produces how many zombies matched), and store catches that number and saves it. There are five places it can save to (a block, a bossbar, an entity, a score, or a storage), with syntax like:

store (result|success) score <targets> <objective> -> execute

You don’t have the tools to use the saved number yet: scores live in Chapter 11 and command storage in Chapter 12, and the deeper store patterns wait for Chapter 27. For now, just recognize the word: when you see execute store result score ... in someone else’s pack, it means “run this and remember the number it gives back.” We’ll come back and wire it up properly later.

run — the final step

Every chain ends with run. Its single argument is the command to be executed, whose context variables may be modified by the subcommands used. In other words, run is where you put the actual command, and all the as/at/if pieces before it have already set up the who, where, and whether.

Two rules keep you out of trouble:

• run can be used only once, at the very end. You can stack as many as, at, and if subcommands as you like, but run finishes the line.
• A chain that doesn’t end in run is only legal if it ends in a condition (if/unless). Only a run subcommand or a condition subcommand may finalize the chain; otherwise, the command is unparseable. If you end on as or at with nothing after, the game rejects the line.

Walkthrough: building a chain one piece at a time

The best way to understand a long /execute is to grow it. Let’s build up a command that warns you about nearby zombies, subcommand by subcommand, typing each version into chat as we go.

Start with the plainest version, just a message:

/say Checking for zombies...

Now make it speak as each zombie:

/execute as @e[type=zombie] run say I am a zombie.

If three zombies are loaded, that line forks into three branches and you get the message three times, once per zombie, each running as that zombie. Finally, only warn when zombies are actually close, by adding a condition. The finished pair of commands:

/execute if entity @e[type=zombie,distance=..16] run say A zombie is within 16 blocks! /execute as @e[type=zombie,distance=..16] at @s run say A zombie stands here.

The first line uses if entity as the last subcommand-before-run: the message fires once, only when at least one zombie is within 16 blocks. The second line forks over every nearby zombie and runs as and at each one. Type each into chat and press Enter to try it.

Practice 1 — if a player stands on gold, give them an effect

Now the real thing. We want: for every player, check the block under their feet, and if it’s a gold block, give them a potion effect. This is the wool example from earlier with two swaps: wool becomes gold, and kill becomes effect give. The effect command’s syntax is effect give <targets> <effect> [<seconds>] [<amplifier>]. Place a gold block, stand on it, open chat, and type:

/execute as @a at @s if block ~ ~-1 ~ minecraft:gold_block run effect give @s minecraft:speed 2 1

Read it left to right: as @a (for each player) at @s (at that player’s spot) if block ~ ~-1 ~ minecraft:gold_block (if the block one below is a gold block) run effect give @s minecraft:speed 2 1 (give self Speed for 2 seconds at amplifier 1). Typed once in chat, it gives you a 2-second burst of Speed if you’re standing on gold. To make it a constant boost that refreshes every tick while you stand on the gold, you’ll later put this exact line in a repeating command block (Chapter 6) or in a function that runs every tick (Part III). For now, type it by hand to watch the condition work.

Figure (to be captured). player standing on a single gold block with the Speed effect icon showing in the corner

What Went Wrong? Effect won’t apply? The most common cause is the block ID. Make sure you’re testing for a block ID like minecraft:gold_block, not an item: a gold ingot is an item, not a block, so if block will never match it. Also check the offset is ~ ~-1 ~ (one below) and not ~ ~ ~ (the block you’re standing inside, which is air).

Practice 2 — as every zombie, at its position, summon lightning

This one is pure spectacle and shows off forking. We want to run, for every zombie, summon lightning_bolt at that zombie’s own position. The summon command (Chapter 1) is summon <entity> [<pos>]; with no position it summons at the execution position, which is exactly what at @s sets up. Summon a few zombies, then type:

/execute as @e[type=zombie] at @s run summon minecraft:lightning_bolt

as @e[type=zombie] forks over every zombie; at @s moves the position onto each one; and summon minecraft:lightning_bolt (with no coordinates) strikes at that position. Because the chain forks, one short line strikes every zombie at once.

Figure (to be captured). several zombies being struck by lightning at once, one bolt per zombie

Try It! Add a condition so only nearby zombies get hit: change the selector to @e[type=zombie,distance=..20]. Or make it rain effects instead of lightning — swap the run for run effect give @s minecraft:glowing 30 0 so every zombie lights up. Notice how only the last part (after run) changes; the as ... at @s scaffolding stays the same. That scaffolding is the reusable heart of /execute.

What Can Go Wrong

Forgetting at after as. This is the number-one beginner mistake. /execute as @e[type=zombie] run summon lightning_bolt makes each zombie the executor, but it never moves the position, so all the lightning strikes at your feet instead of at the zombies. Whenever you want something to happen where an entity is, you almost always need as <sel> at @s together, not as alone.

Putting run in the wrong place, or twice. run must be last, and may appear only once. A line like /execute run say hi as @e won’t work because nothing is allowed after the run command. And a chain that ends on a modifier with nothing after it (/execute as @a at @s) is “unparseable,” because only a run or an if/unless may finish a chain.

Mixing up @s and the position. Remember that as changes the executor (@s) and at/positioned change the position (~ ~ ~): they’re two separate things. If your command targets the wrong entity, check your as. If it happens in the wrong place, check your at. The bug is almost always one of those two, in the wrong order or missing entirely.

What You Know Now

You can read and write the most important command in the game. You know that /execute runs another command after changing the executor (as), the position (at, positioned), and the condition (if/unless), and that the chain always finishes with run plus the real command. You understand forking (that a multi-entity selector makes the rest of the chain run once per entity) and you’ve used it to act on every zombie at once. You’ve previewed store and the if score / if predicate / if data conditions, which unlock fully once you learn scoreboards (Chapter 11), command storage (Chapter 12), and predicates (Chapter 18). You’ve typed live /execute lines that warn about nearby zombies, boost players standing on gold, and call lightning down on every zombie at once. From here on, /execute shows up in almost every chapter. It’s the glue that holds programmable data packs together.