Bedrock Allowlist, Operators, Ban and RCON Limits

Map the action to a documented Bedrock control

• Private admission: allowlist on/off/add/remove/list/reload and allow-list=true.
• Temporary removal: kick with a reason.
• Operator role: op and deop; inspect/reload current permission state with permission commands.
• Maintenance: use the exact-build save help and stop; do not emulate success by killing the process.

Do not invent player identity

A server-status response may expose only a connected-player count. That is not evidence that the first connected person is named Player 1, and a synthetic Steam-style ID has no place in Bedrock’s Xbox identity model.

1. 1Use a documented player list/console event only when it supplies an actual name or identity.
2. 2If only a count is available, display the count and mark individual names unavailable.
3. 3Require the administrator to choose or enter an exact verified Gamertag for allow-list/operator changes.
4. 4Redact Gamertags and XUIDs from screenshots and exported support bundles.

Use allow-list removal instead of a fictional ban

The current official command list contains kick and allowlist but no ban, ban-ip, pardon or published ban-file entry. On a closed server, removing the Gamertag from allowlist.json prevents future admission while kick ends the current session.

• Keep allow-list enabled before relying on removal for access control.
• Run allowlist reload after an external JSON edit, or use commands so reload is explicit.
• Do not label platform-level Microsoft/Xbox blocking as a BDS ban.
• Record the command result; never turn an unsupported operation into a success toast.

Separate player permissions from script capabilities

The BDS player permission file used by op/deop/permission commands is conceptually different from config/default/permissions.json, which grants Script API modules to behavior-pack code. Editing script capabilities does not make a player an operator.

• Manage player ranks with op, deop and permission list/reload.
• Keep default Script API permissions minimal and extend only a reviewed module UUID when required.
• Treat script variables/secrets as sensitive configuration and exclude them from public diagnostics.
• Keep script-debug listeners disabled on production unless a controlled development session needs them.

Use an action-and-evidence matrix

1. 1For admission, verify allow-list=true, run the documented allowlist command with the exact Gamertag, and test one approved plus one unapproved account.
2. 2For temporary removal, issue kick to a verified connected name and record the console response; do not infer a persistent ban from the disconnected session.
3. 3For elevated commands, apply op/deop to the intended identity, then test one harmless operator-only action and remove elevation when no longer needed.
4. 4For a panel player list, compare names against a documented console/list source. If the source yields only a count, suppress per-player kick/role controls.
5. 5For automation, send only a command confirmed by help on that installed BDS build and report the raw result accurately when it is rejected.

Interpret command and service failures precisely

A syntax or unknown-command response shows that the local command channel worked but the requested capability or form is unsupported. A target-not-found result means the command exists but the supplied identity was not resolved. An unchanged allow-list after hand-editing points to JSON validity, wrong file/working directory or a missing reload—not an RCON outage.

A generic panel message such as ‘service could not be reached’ must not overwrite the underlying distinction. Preserve whether the transport failed, BDS rejected a command, or the product never had a documented Bedrock implementation. That separation prevents an administrator from changing internet settings to repair an absent native feature.

• Unknown ban or RCON action: hide/disable it for BDS and explain the documented alternative.
• Kick target unresolved: refresh documented identity evidence; never fall back to a synthetic Player 1 label.
• Allow-list entry present but join denied: verify exact Gamertag/Xbox authentication and reload before recreating files.
• Operator change accepted but action denied: inspect current permission state and exact command requirement without broadening Script API permissions.

Use console/stdin instead of public RCON

Mojang’s current BDS materials do not document a native RCON endpoint. Send supported commands through the local process console/stdin or implement a deliberately permissioned Script API extension. Before changing files or restarting during diagnosis, enter stop and take a complete off-tree recovery copy.

Set a stop and rollback boundary for access changes

Routine allowlist, kick and operator commands should not require world replacement. Stop the server only when changing files/configuration that the exact build cannot safely reload, installing a reviewed script extension or taking a consistent recovery snapshot. Wait for normal exit, preserve the active world plus server.properties, allow-list/player-permission state, packs and script config, then test the change on a private copy.

Rollback restores that matched state after the process is stopped. Do not copy an old permissions file into a running server, do not delete a world to repair an access-list problem, and do not expose a debugger or improvised web command bridge to bypass missing native RCON.

Recheck the capability surface after BDS updates

• Run current help/command discovery and compare it with the controls the product exposes.
• Review Microsoft’s command and scripting references before claiming that a missing control remains unavailable in every future build.
• Regression-test allow-list admission, kick, op/deop, permission reload and an honest unknown-player display.
• Keep public support screenshots free of Gamertags, XUIDs, access tokens, debug ports and script secrets.
• Record unsupported actions as explicit capability gaps so they cannot silently become generic connectivity errors again.