Lmcq Auth LoRA Decryption

This is the node you use if someone sold or shared you a LoRA encrypted with LmcqAuthLoraEncryption - it takes an existing MODEL and CLIP, applies the decrypted LoRA to both, and hands them back out, same shape as a normal LoraLoader. If you've used any standard LoRA node before, the mechanics here won't surprise you; the only difference is the extra password gate in the middle.

How it wires up. model and clip come in from your checkpoint loader, same as any LoRA node. lora_name is a dropdown of the encrypted LoRA files sitting in your loras folder. key is the password the creator used to encrypt it - get it exact, it's case-sensitive and there's no partial-match forgiveness. strength_model and strength_clip (both default 1, range -20 to 20) control how strongly the LoRA's effect is applied to each - same knobs you'd expect from any LoRA loader, and yes, the range goes well past 1.0 and into negative territory if you want to invert or overdrive the effect, though anything outside roughly -2 to 2 is unusual territory worth experimenting with carefully. Two outputs come back out: MODEL and CLIP, ready to wire into your sampler and text encoder same as always.

Why this exists instead of just a normal LoraLoader. Because the file itself is encrypted - a stock LoraLoader has no idea what to do with it. This node is the only thing in the pack (paired with LmcqRuntimeLoraDecryption for the non-cloud variant) that can turn an LMCQ-encrypted LoRA back into weights ComfyUI can actually apply.

What "Auth" means here versus the pack's other decryption family. This is part of LMCQ's cloud-backed authentication system - per the README, decryption can involve a real-time check against LMCQ's own auth server (validating machine binding, usage limits, expiration) rather than a purely local password comparison. That's meaningfully different from the pack's "Runtime" family (LmcqRuntimeLoraDecryption), which does everything locally with no server dependency. If this node fails and you suspect it's not the password, a missing internet connection or an LMCQ server outage is worth ruling out before you assume the file is bad - that's not something you can diagnose or fix locally, though, since the pack doesn't expose any way to check server status from inside ComfyUI.

Installing it. Through ComfyUI Manager (search "ComfyUI-LMCQ") or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/sebord/ComfyUI-LMCQ

Restart ComfyUI afterward.

The bug that actually causes most of the reported trouble. This pack's Auth and Runtime nodes share a compiled, obfuscated protection module, and on some installs that module goes missing entirely, throwing a ModuleNotFoundError on startup (runtime.model_protection or api_model_protection, depending on which variant your install shipped). Because the failing import lives in the pack's shared __init__.py, it crashes registration of the whole pack - this decryption node included, along with everything unrelated to encryption, like the image saver or the Flux NF4 loader. If LmcqAuthLoraDecryption isn't in your node search at all, check your ComfyUI startup log for that error before assuming anything about your password or your LoRA file. The pack's January 2026 changelog has the fix: copy the runtime files matching your installed Python version into the runtime folder, delete whichever ones don't match, and restart.

If the node does load and decryption still fails, the mundane explanations come first: wrong password, a corrupted or incompletely-downloaded file, or - if the LoRA was machine-locked - running on hardware that was never added to the authorized machine-code list, which only the original creator can fix by re-encrypting with your machine code included.