Mixins on 26.1

Checked against the Mixin wiki, Fabric’s documentation and blog, and a draft page on Fabric’s wiki, on 2 November 2026.

What changed

Up to 1.21.11 the game you ran was obfuscated: classes and methods had scrambled names. Your mixin used readable names, so something had to translate them for the real game. From 26.1 the game runs with Mojang’s names (Fabric, 31 October 2025), and Fabric’s new Gradle plugin, net.fabricmc.fabric-loom, does not remap Minecraft or mods (Fabric, 14 March 2026). The names you write in a mixin are the names the game has.

Why refmaps existed

Mixins name their targets in strings inside annotations: the method in method = "...", the call in @At(target = "..."). The Mixin wiki calls these “soft references”. The remapping tool it describes (SpecialSource) can’t rename them, so Mixin’s annotation processor wrote a refmap: a file in the jar that maps each soft reference to its obfuscated name. The mixin config names it with the refmap key (Mixin wiki: Obfuscation and Mixins, The Mixin Environment).

On Fabric this changed before 26.1. Loom’s options page says the useLegacyMixinAp switch is off by default from Loom 1.12, and that when it is off, Tiny Remapper remaps mixins instead of the annotation processor (Loom: Extension Options). Fabric’s wiki has a draft page, Mixins and Obfuscation, that adds two points: with current Loom no refmap is needed, and unobfuscated versions need no mappings and no remapping at all. It is a draft, so check it again before you rely on it.

In Linen’s own Fabric templates, the mixin config has no refmap key on 1.20.1 or on 26.1.2. The one line that differs is compatibilityLevel: JAVA_17 on 1.20.1, JAVA_21 on 1.21.x and JAVA_25 on 26.x.

What to check after moving to Mojang names

Fabric’s migration pages say to review mixins by hand after migrateMappings, and to look for outdated mixin targets (Fabric docs). For each mixin:

1. The class in @Mixin(...) exists under its Mojang name.
2. Each method = "..." names a method that still exists in 26.1, with the same parameters.
3. Each @At(target = "...") uses Mojang names for every class in the descriptor.
4. The mixin still applies. A missing target class is only a warning in the log by default; a required injector that finds nothing stops the game. See Mixin target not found.

Moving to Mojang names is only half of it. Mojang also changed the game’s code in 26.1, so a method you target may be renamed, moved or gone. NeoForge’s 1.21.11 → 26.1 primer lists those changes for any loader.

Local variables by name

Fabric’s draft page notes that on unobfuscated targets you can capture a local variable by name with MixinExtras’ @Local(name = "..."), instead of by position, which breaks easily between versions. It also notes a bug with capturing method parameters by name that is fixed in the Mixin that ships with Fabric Loader 0.18.4 and newer; older versions see parameters as arg0, arg1 and so on.

What the sources don’t say yet

• remap = false. Fabric’s draft explains remap = false for obfuscated versions. We found no official page that says what remap does on 26.1, so this page doesn’t tell you to add or remove it.
• NeoForge. NeoForge’s 26.1 post doesn’t mention mixins or refmaps. Its build changes are a newer Gradle plugin, Gradle 9.1.0 or newer, Java 25, the new NeoForge version, and dropping Parchment if you want (NeoForge 26.1 porting notes).

In Linen

• Linen Check reads your mixins with the rest of the mod and names the file and the fix.
• Minecraft’s code and Find usages browse the decompiled game for your project’s version, on your machine, so you can check that a target method exists in 26.1 and what it is called.
• Run and Play the game start the dev client with the Game Log. If a mixin breaks the game, Crash Doctor says why.
• Claude Code, Anthropic’s extension, on your own Claude plan, gets Linen’s tools (lookup_symbol, search_source, linen_decompile, linen_mappings and others) and Linen Check after every edit. Ask it to check each mixin’s targets against 26.1.