Script Privileges and Read-Only Execution Mode

When the Bedrock scripting engine executes your code, it assigns an execution privilege level to the current call stack. In standard contexts—such as inside `system.runInterval`, `afterEvents` callbacks, or custom command handlers—your script has full read-write privileges. It can freely spawn entities, change block permutations, modify dynamic properties, or apply knockback.

However, when the engine is in the middle of resolving an internal game mechanic, it locks the world state before invoking your script. During this window, your code can read properties (like checking an entity's health, reading a block's type, or inspecting an item stack), and it can modify the specific event payload passed into the callback (such as setting `event.cancel = true`). Any attempt to call a method or set a property that mutates the broader world will immediately throw a runtime exception and halt the execution of that callback.

Different entry points into your script carry different privilege states. The table below outlines the primary execution contexts in `@minecraft/server` and what you are permitted to do inside them.

The most common place creators encounter privilege restrictions is inside `world.beforeEvents`, such as `playerBreakBlock`, `itemUse`, or `chatSend`. These events fire after a player or entity initiates an action, but before the game engine commits the result to the world.

Because the engine's internal C++ state is mid-transition during a `beforeEvent`, allowing scripts to delete the acting entity, overwrite the block being broken, or teleport the player would invalidate memory pointers the engine is actively holding. To prevent hard crashes, Mojang marks all world-mutating APIs as requiring full privileges. If you call `player.teleport()`, `dimension.spawnEntity()`, or `entity.addEffect()` directly inside a `beforeEvents` listener, the call is blocked.

When you need to both cancel an action (which requires a `beforeEvent`) and mutate the world in response (which requires read-write privileges), you bridge the gap using `system.run()`. Calling `system.run(callback)` is safe inside read-only mode because it does not mutate the world; it merely queues a JavaScript function to run during the scripting phase of the current or next game tick, once full privileges are restored.

One critical detail when deferring execution out of a `beforeEvent` is that the event object's properties may be invalidated or recycled once the event finishes firing. Furthermore, object references like `event.block` continue to point to a specific coordinate in the dimension, meaning if the block changes before `system.run` executes, reading it later yields the new state. Always capture primitive values (strings, numbers, vector coordinates) or persistent references (like the `Player` object) into local variables before entering the `system.run` closure.

import { world, system } from "@minecraft/server";

world.beforeEvents.playerBreakBlock.subscribe((event) => {
    const { player, block, itemStack } = event;

    // Reading properties is allowed in read-only mode
    if (block.typeId === "minecraft:diamond_ore" && itemStack?.typeId === "minecraft:wooden_pickaxe") {
        // Modifying the event payload is allowed in read-only mode
        event.cancel = true;

        // Capture coordinates before the event context closes
        const blockLoc = { x: block.location.x, y: block.location.y, z: block.location.z };
        const dim = block.dimension;

        // Defer world mutations to a privileged tick context
        system.run(() => {
            // Now in Read-Write mode: mutating the world and player is safe
            dim.setBlockType(blockLoc, "minecraft:cobblestone");
            player.sendMessage("§cYour wooden pickaxe shattered the diamond into cobblestone!");
            player.playSound("random.break");
        });
    }
});

Another subtle privilege boundary occurs when your script file is first imported and evaluated at the very start of world load. During this top-level execution phase, you can subscribe to `beforeEvents` and `afterEvents`, and you can schedule `system.runInterval` timers. However, the world dimensions and entities have not finished loading.

Attempting to query `world.getDimension("overworld").getEntities()` or set world dynamic properties directly at the top level of `main.js` will either fail or return empty results. If you need to run one-time setup logic that mutates or queries the world upon load, wrap it in `world.afterEvents.worldInitialize.subscribe()` or defer it with `system.run()`.

Applies to Bedrock Edition 1.20.0 and newer using stable `@minecraft/server` versions (1.4.0+). In older 1.19.x experimental versions, `beforeEvents` were located under `world.events.before*`, though the read-only restriction and `system.run` workaround functioned identically. No experimental toggles are required for standard event privilege handling in current versions.

Read out of the game itself, so the ids match the version you are building for.