Mixin target not found

Checked against the Mixin source and wiki and Fabric’s documentation on 2 November 2026.

The messages

Mixin prints one of these in the game log. The text comes from Mixin’s own code (MixinInfo.java, TargetSelectors.java, InjectionInfo.java):

@Mixin target <class> was not found <your mixin>
Critical injection failure: <injector> could not find any targets matching <method> in <class>.
Critical injection failure: <injector> <handler> in <your mixin> failed injection check, (0/1) succeeded. Scanned 1 target(s).

• “@Mixin target … was not found”: the class in @Mixin(...) doesn’t exist. By default this is only a warning and your mixin is skipped, so the game may start without it. The system property mixin.debug.strict.targets=true turns it into an error (Mixin wiki: system properties).
• “could not find any targets matching”: the class exists, but no method matches the method = "..." you gave.
• “failed injection check”: the method was found, but the injection point (@At) matched nothing in it.

The last two stop the game when the injector is required. Mixin throws an error when an injector gets fewer successful injections than its require value, and "injectors": { "defaultRequire": 1 } in the mixin config makes every injector required (Inject.java, MixinConfig.java). Fabric’s template, and Linen’s, set defaultRequire to 1.

Fixes

1. Check the name for this exact version. Classes and methods get renamed between versions, and between name sets. After moving from Yarn to Mojang names, Fabric says to check for outdated mixin targets (Fabric docs). On 26.1 your mixin must use Mojang’s names, because the game runs with them.
2. Check the parameters. If the class has several methods with the same name, the name alone may pick the wrong one. Add the descriptor after the name, for example method = "tick()V". Mixin’s target selectors take a name with a descriptor (ITargetSelector.java).
3. Check the injection point. In @At(target = "..."), every class in the descriptor must use the right name for this version, and the call must still be in that method in this version.
4. Check the side. In the mixin config, mixins applies on both sides, client only on the client and server only on the dedicated server (Mixin wiki: The Mixin Environment). A mixin into a client-only class belongs under client.

See what Mixin did

Two system properties from the Mixin wiki:

• mixin.debug.verbose=true prints Mixin’s debug messages at normal log level.
• mixin.debug.export=true writes every class after mixins are applied to .mixin.out in your run folder.

Add them to the run. Loom 1.17 and newer (Loom: Extension Options):

loom {
    runs {
        client {
            systemProperties.put("mixin.debug.verbose", "true")
        }
    }
}

ModDevGradle (NeoForge), the same way the MDK sets its other properties:

neoForge {
    runs {
        client {
            systemProperty 'mixin.debug.verbose', 'true'
        }
    }
}

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 see the real class, method and parameters.
• Hovers show names in Mojang, Yarn, intermediary and Parchment, where the version has them.
• Play the game shows the Game Log; if a mixin stops the game, Crash Doctor says why.