Lmcq Runtime Lora Decryption

This is what loads a LoRA encrypted with LmcqRuntimeLoraEncryption - take your MODEL and CLIP in, apply the decrypted LoRA to both, get them back out. It behaves exactly like a normal LoraLoader in terms of wiring; the only difference is a key field standing between you and the actual weights.

The fields. model and clip come in from your checkpoint loader, same as any LoRA node. lora_name is a dropdown of the encrypted LoRA files it finds locally. key is the password set at encryption time - has to match exactly. strength_model and strength_clip (both default 1, range -20 to 20) are the usual LoRA strength sliders, controlling how strongly the effect applies to the diffusion model versus the text encoder respectively; nudge them down toward 0 for a subtler effect, or push past 1 if you want it stronger than the LoRA's default training intensity. Two outputs come back: MODEL and CLIP, wired onward exactly as you would for any unencrypted LoRA.

No password server, by design. This decryption node doesn't touch a network - there's no equivalent of the Auth family's cloud validation here. If the LoRA was locked to specific hardware at encryption time, that check happens automatically against the machine you're running on, and you don't enter anything for it; there's no machine_codes field on the decryption side, only on encryption. Per the README, this whole "Runtime" system decrypts the LoRA into memory for the duration of the run and never writes an unencrypted copy back to disk - which is the actual value proposition here versus a plain password-protected zip file: even with the right key, there's no simple "extract and keep" step.

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.

Troubleshooting. Start by checking whether the node loaded at all, because this pack has a genuinely common, well-reported failure that has nothing to do with LoRAs or passwords: a compiled runtime module the protection system depends on has gone missing on some installs, throwing ModuleNotFoundError: No module named '...runtime.model_protection' at ComfyUI startup. Because that import failure happens inside the pack's shared __init__.py, it takes down the entire pack's node registration - if this node is missing, every other Lmcq node is missing too, including ones with nothing to do with encryption. The pack's January 2026 changelog documents the fix: copy the Python-version-matching runtime files into the runtime folder, delete the ones that don't match, and restart.

If the node loads but decryption fails, work through the ordinary suspects: copy-paste the key rather than retyping it to rule out a typo, confirm the file wasn't corrupted or partially transferred, and if you know it was machine-locked, confirm your current machine's code was actually included when the file was encrypted. That last one is the one case with no local fix - since this whole system is intentionally offline with no server to update the authorized list, the only remedy is asking whoever encrypted the file to add your machine code (via LmcqGetMachineCode) and send you a freshly encrypted copy.