Guides / Commands & Data

/execute: why as/at order matters and how store actually works

Most broken execute chains come from confusing who runs the command with where it runs. Here is what each subcommand changes, and the order that fixes it.

2026-07-20

/execute is one command pretending to be a scripting language. Almost every failure traces to two subcommands that sound like they do the same thing and do not.

as changes WHO. at changes WHERE.

• as <target> — swaps the executor. @s now means that entity. **The position does

not move.**

• at <target> — swaps the position, rotation and dimension. **The executor does not

change.**

So this does nothing useful:

execute as @e[type=zombie] run setblock ~ ~ ~ stone

It runs once per zombie, but always at your feet, so it places one block over and over. The fix is both:

execute as @e[type=zombie] at @s run setblock ~ ~ ~ stone

at @s re-anchors to the zombie that as just selected. as … at @s is the single most common pairing in the whole command, and forgetting at @s is the single most common bug.

Order is left to right, and it compounds

Subcommands run in sequence, each modifying the context the next one sees:

execute as @a at @s positioned ^ ^ ^3 run particle flame

1. as @a — one pass per player
2. at @s — move to that player
3. positioned ^ ^ ^3 — 3 blocks in front of where they are looking

Swap steps 2 and 3 and the caret offset is measured from your rotation instead of theirs.

Caret versus tilde

• ~ ~ ~ — relative to position, aligned to the world axes
• ^ ^ ^ — relative to facing: left, up, forward

Caret coordinates are why positioned ^ ^ ^3 means "in front of" and ~ ~ ~3 means "3 blocks south". Mixing the two notations in one coordinate triple is a syntax error.

store is a return value, not a variable

store captures what the command returns — usually a success count or a result value:

execute store result score @s Count run data get entity @s Inventory

Two things people get wrong:

• result versus success. result is the number the command produces; success

is 1 or 0 for whether it ran. Counting entities needs result.

• store goes before run, and it applies to the command after run, not to the

subcommand chain.

if versus unless short-circuits

if and unless filter — the chain stops there when the test fails. Multiple if clauses are an AND. There is no OR; that needs two separate commands or a predicate.

execute as @a if entity @s[gamemode=survival] if score @s Lives matches 1.. run ...

Build the chain a subcommand at a time, with the context shown at each step, in the Advanced Command Builder — it also covers data, item, loot, schedule, particle and playsound from the same form.

Open the Advanced Command Builder — Execute & Data →