Evidence boundary: This guide was source-checked on August 25, 2026. MineBrush reviewed current official text and built an original static evidence ladder. We did not launch Minecraft, attach an add-on, open a world, sign into an account, join a Realm, or unlock an achievement for this package.
Minecraft Bedrock 26.30 changed a sentence that players used as a shortcut for a much bigger question. Mojang's changelog says the game removed warning text about not being able to earn achievements when a player creates a world with Add-ons enabled. The safe reading is narrow: a warning sentence was removed from that creation flow. The line does not say that every add-on is now achievement-friendly, that an old world's status changed, or that an absent warning guarantees an unlock.
Quick answer: what changed?
| Question | What the official source supports | MineBrush verdict |
|---|---|---|
| Was the add-on achievement warning text removed in 26.30? | Yes. The 26.30 changelog explicitly records that UI-text removal. | Confirmed for the documented 26.30 change. |
| Does that sentence say add-ons always preserve achievements? | No. The changelog does not make that policy claim. | Unknown; do not promote the UI note into a universal rule. |
| Does no warning on screen prove this world is eligible? | No official source retrieved for this package defines warning absence as an eligibility test. | Not proven. |
| Do cheats still matter? | Yes. Mojang's current commands guide says enabling Allow Cheats in Bedrock single-player permanently stops achievement unlocking in that world, even if cheats are later turned off. | Check world history before trusting a clean-looking toggle. |
The changelog line is a UI fact, not a result
A changelog describes many kinds of changes: mechanics, fixes, labels, dialogs, and presentation. This particular line names warning text. Removing that warning does not prove achievement eligibility. The line does not name an achievement engine rule, an account service change, a retroactive world migration, or a tested add-on class.
There is another useful clue in the same release notes. Mojang separately says 26.30 added an achievements-disabled warning modal to the Realms Edit World screen. Those two bullets point to two interface surfaces changing in one release: one message was removed from add-on world creation, while another warning modal was added to Realm editing. They do not combine into a universal eligibility policy.
That distinction matters because players can see less warning text without the underlying state of a specific world being established. Likewise, a warning can appear because the game has detected a condition, but the existence of the modal does not explain every cause or every platform path.
What official achievement guidance still confirms
The strongest current Minecraft-specific rule retrieved for this package concerns cheats. Mojang's player guide to commands says that turning on Allow Cheats in Bedrock single-player permanently stops players from unlocking achievements in that world, even after the toggle is turned off again. Microsoft Learn's current commands introduction independently states that enabling cheats disables achievements for the world.
This means “cheats are off now” and “cheats were never enabled” are different claims. A current setting can show the first. It cannot, by itself, prove the second. Do not edit world data, use unofficial tools, or follow a video that promises to erase history just to force an unlock. That would replace a legitimate eligibility question with an unsupported modification and could damage the save.
The current Minecraft Help article for activating Add-ons explains how players activate resource or behavior packs in a new single-player world, an existing world, or a Realm. Its retrieved text does not establish whether a resulting world can earn achievements. Successful activation therefore proves that the pack was accepted into that setup flow; it does not prove the achievement outcome.
A five-step evidence ladder
- Freeze the exact build. Record the full Bedrock version shown on the device. The warning change is documented for 26.30; this article does not claim identical wording in every later retail, Preview, console, mobile, or PC build.
- Separate resource and behavior layers. Write down exactly which packs are active. If the download contains more than one layer, use MineBrush's Behavior Pack vs Resource Pack guide to identify them. Do not assume a texture-only layer and a behavior-changing layer have the same effect.
- Record world history, not only current toggles. Note whether the world was ever opened with Allow Cheats enabled or in a workflow that activated cheats. If you do not know, mark that history unknown instead of guessing.
- Treat creator labels as claims. “Achievement friendly,” “Survival safe,” or a missing warning can be useful leads, but none is an independent account result. Save the creator URL, release name, version claim, and date so the claim can be checked later.
- Require a controlled result for a verdict. A meaningful test needs the exact build, platform, account state, world, active pack set, achievement objective, start condition, action, and observed unlock or non-unlock. MineBrush did not perform that test here, so this guide stops before a verdict.
Before you invest hours in an add-on world
Make the decision reversible. Keep the original world untouched, preserve the creator's original package where its license and distribution terms allow, and work in a duplicate. If you are updating an existing pack, follow the safe Bedrock add-on update workflow so a failed import or behavior change does not overwrite the only working setup.
- Record the world name, Bedrock build, device family, account used, and current game mode.
- List every active resource pack, behavior pack, experiment, and add-on release.
- Capture whether Allow Cheats is currently on, off, or unknown; do not equate “off” with “never enabled.”
- Keep creator claims separate from MineBrush observations and official source facts.
- Choose one normal achievement whose prerequisites you understand; do not use an already-earned account achievement as if it were a fresh test.
- If the unlock fails, preserve the exact steps and use the official Xbox achievement troubleshooting route rather than promising a world-file fix.
This checklist reduces bad conclusions, but it still does not certify eligibility. A missed unlock can have more than one explanation, and this package did not retrieve official text that ranks those causes. A single non-unlock is not automatically proof that the whole world is disabled. A single successful unlock is evidence for that exact tested tuple, not a lifetime promise for every future add-on or update.
Three common claims that go too far
“The warning is gone, so achievements work”
Unsupported. The changelog confirms removal of text. It does not state a universal eligibility rule or report a controlled account result.
“My add-on imported, so the world is safe”
Unsupported. Import and activation are different evidence from saving, reopening, gameplay compatibility, and achievement unlocking. Test those jobs separately.
“Cheats are off, so this world is clean”
Incomplete. The official rule addresses enabling cheats, and Mojang says turning them off later does not restore achievement unlocking for that world. Current state alone does not establish history.
What remains explicitly unknown
This package does not determine whether a particular downloaded map, Marketplace add-on, creator pack, resource pack, behavior pack, experiment, existing save, Realm, server, device, or platform is achievement-eligible. It does not map 26.30 behavior to 26.40, 26.45, a Preview build, or a future release. It does not establish whether adding or removing a specific pack changes an existing world's stored state. It also does not provide a per-platform account or trophy rule.
The old Minecraft Help URL named “Minecraft Achievements FAQ” returned a generic Help shell during this source check rather than readable FAQ text. The current Xbox achievement troubleshooting URL also required its script-driven application and supplied no retrievable Minecraft world-policy text to this package. Their existence is recorded as a support-route observation, not used to fill the missing policy with memory or community lore.
How MineBrush tested the reasoning
The package includes an original static evidence-ladder fixture. Its validator accepts the narrow 26.30 source fact and keeps world eligibility unknown. It also accepts the official cheats rule when a hypothetical player's own record says cheats were enabled, while still refusing to claim that MineBrush observed that world.
Seven tempting mutations are rejected: changing “warning removed” into “eligible,” treating no visible warning as proof, trusting a creator label as a result, turning “cheats off now” into “never enabled,” treating one missed unlock as proof that all achievements are disabled, treating the presence of a support URL as policy, and treating successful add-on activation as an achievement test. The fixture is synthetic; it contains no Minecraft capture, account data, add-on files, or creator media.
Bottom line
Bedrock 26.30 removed a warning sentence from the add-on world-creation flow. That is useful and worth documenting, but it is not a green light for every world. Preserve the exact build and pack tuple, respect the official cheats rule, separate creator claims from observed results, and leave eligibility marked unknown until an exact, controlled account test or a clearer current official policy answers it.
Primary references: the official Minecraft Bedrock 26.30 changelog, Mojang's commands guide, Microsoft Learn's commands introduction, Minecraft Help's Add-on activation guide, and the official Xbox achievement troubleshooting route. Browse more source-first release coverage in the MineBrush Minecraft Updates archive.

PLAYER QUESTIONS
Discussion
Include the exact edition, version and step when asking for help.