ComfyUI IMPORT FAILED: How to Fix Custom Node Errors

The summary block at the end of startup ("Import times for custom nodes") only tells you which pack died and how long it took. The cause is earlier. ComfyUI writes the full startup output to user/comfyui.log, or comfyui_<port>.log if you run on a non-default port, and keeps the two previous boots as .prev.log and .prev2.log. Search all of them at once:

# Windows (PowerShell), from the ComfyUI folder
Select-String -Path user\comfyui*.log -Pattern "Cannot import|IMPORT FAILED|Error importing|Python executable"

# Linux / macOS
grep -nE "Cannot import|IMPORT FAILED|Error importing|Python executable" user/comfyui*.log

Here's what a real one looks like, trimmed from my server's boot on October 27:

** Python executable: C:\AI\ComfyUI\venv\Scripts\python.exe
...
  File "...\ComfyUI-3D-Pack\Gen_3D_Modules\Stable3DGen\stablex\controlnetvae.py", line 19
    from diffusers.models.controlnet import ControlNetOutput
ModuleNotFoundError: No module named 'diffusers.models.controlnet'

Cannot import ...\custom_nodes\ComfyUI-3D-Pack module for custom nodes: No module named 'diffusers.models.controlnet'
...
Import times for custom nodes:
   10.3 seconds (IMPORT FAILED): I:\AI\ComfyUI\custom_nodes\ComfyUI-3D-Pack

Read three things: the exception after "module for custom nodes:", the last file in the traceback, and the Python executable at the top of the log. The last file tells you whether the crash happened in the pack's own code or in a library it imports. The executable tells you which environment you need to fix. That second point turned out to matter more than anything else.

My ComfyUI box is a Windows machine with an RTX 5090 and 74 custom node entries. It's been through ComfyUI 0.21.1 and 0.33.0 this year, two install paths and two Pythons. Across nine retained startup logs (May 22 to October 27, 2026) there were 17 IMPORT FAILED lines. Grouped by the actual exception:

Only the second row is the classic "missing dependency", and even that one wasn't really about missing packages.

Errno 22: nine packs killed by a print()

On July 5, eleven packs failed in one boot. Nine of them died the same way, on the most innocent line imaginable. In Comfyroll's case it was its __init__.py calling print("------------------------------------------"). That print went through ComfyUI-Manager's output wrapper (prestartup_script.py), which called flush() on the original stdout, which raised OSError: [Errno 22] Invalid argument.

Nothing was wrong with those nine packs. The process had no usable stdout underneath ComfyUI. All nine (Comfyroll, rgthree, tinyterra, controlnet_aux, RES4LYF, ReActor, two WAS suites and an optical-realism pack) load cleanly on the same machine today with no code changes. If you see this error, don't reinstall anything. Look at how ComfyUI was started: a detached process, a service wrapper or a scheduler with no console is the usual suspect. Run it from a real console, or redirect stdout and stderr to a file in your launcher, and the whole batch comes back at once.

No module named X: check which Python you fixed

FluxTrainer kept failing on No module named 'imagesize' and SUPIR on No module named 'open_clip', in May and again in July. The log header explained it. Both boots ran on ...\Programs\Python\Python313\python.exe, the system Python, while the requirements lived in ComfyUI's venv. Once the launcher pointed at the venv, both packs loaded in under a second.

# venv install (use the exact path from "** Python executable:")
C:\AI\ComfyUI\venv\Scripts\python.exe -m pip install -r custom_nodes\ComfyUI-SUPIR\requirements.txt

# Windows portable build
python_embeded\python.exe -m pip install -r ComfyUI\custom_nodes\ComfyUI-SUPIR\requirements.txt

Plain pip install picks whatever pipis first on PATH. That's how you end up "installing it three times" and still failing. If you use the Windows portable build, the interpreter is python_embeded\python.exe, and the official custom node troubleshooting guide launches it the same way.

No module named 'diffusers.models.controlnet': the library moved

This one is sneakier, because diffusers is installed. ComfyUI-3D-Pack failed three boots in a row on October 27 because one of its bundled modules imports diffusers.models.controlnet. That path doesn't exist anymore. I checked both Pythons on the box: diffusers 0.40.0 in the venv and 0.37.0 in the system Python both raise ModuleNotFoundError on it, and in 0.40.0 the class lives at diffusers.models.controlnets.controlnet.

When the missing module is a submodule of a library you already have, don't reinstall and don't downgrade. Nine packs on my server import diffusers, including WanVideoWrapper, Frame-Interpolation and layerdiffuse. Pinning an older diffusers for one 3D pack puts the other eight at risk. Update the pack first. If upstream hasn't caught up, a two-line fallback in the failing file is the smallest fix:

try:
    from diffusers.models.controlnet import ControlNetOutput  # diffusers before the move
except ModuleNotFoundError:
    from diffusers.models.controlnets.controlnet import ControlNetOutput  # current diffusers

Keep a note of the patch. The next git pull on that pack will either fix it properly or overwrite yours.

NameError and friends: a bug in the pack

The last failure was a NameError: name 'logger' is not definedinside 3D-Pack's sparse-attention module. It only ran on a warning path, the one that fires when the configured attention backend isn't supported, so most installs never hit it. Mine sets SPARSE_ATTN_BACKEND=sdpain the launcher, so it did. If the last frame of the traceback is inside the pack's own folder and the error is NameError, AttributeError or SyntaxError, it's their bug. Update the pack, read its open issues, or temporarily remove the setting that sends you down that path.

Yes, and this is the case I'd actually worry about. ComfyUI only marks a pack as failed when its top-level import raises. If the pack catches its own errors, ComfyUI reports it as loaded.

ComfyUI-Addoor does exactly that. In every boot it logs nine lines like Error importing RunningHubInit: No module named 'ComfyUI-Addoor', then shows up in the import summary as a healthy "1.0 seconds". The cause is in its rp/__init__.py: it builds the import path from its own folder name, __import__(f'ComfyUI-Addoor.rp.{module_name}'), and a hyphen isn't valid in a Python module name. The live server registers 31 Addoor nodes and zero of the nine RunningHub ones. A workflow that needs those nodes will fail as "missing node type", and the startup summary will swear the pack is fine.

So I don't trust the summary anymore. After every update I count what each pack actually registered, using the same /object_info endpoint ComfyUI validates against:

import json, sys, urllib.request
from collections import Counter

BASE = sys.argv[1] if len(sys.argv) > 1 else "http://127.0.0.1:8188"

req = urllib.request.Request(BASE + "/object_info", headers={"User-Agent": "Mozilla/5.0"})
with urllib.request.urlopen(req) as r:
    info = json.load(r)

packs = Counter(
    spec.get("python_module", "?").removeprefix("custom_nodes.")
    for spec in info.values()
)
for pack, n in sorted(packs.items()):
    print(f"{n:5d}  {pack}")
print(f"{len(info):5d}  total node types")

Run it before and after you update nodes and diff the two outputs. On my server it prints 4,466 node types. A pack that drops from 40 nodes to 31 shows up immediately, IMPORT FAILED or not. Pair it with a search for Error importing in the log. If you drive ComfyUI over the API, the same gap surfaces as missing_node_type, which I covered in ComfyUI prompt outputs failed validation.

The same import summary answers this, and it's worth reading even when nothing fails. On October 27 my server booted three times. Each time ComfyUI-SAM3 took 76 to 90 seconds out of a 102 to 147 second startup. The other 73 entries combined took 16 to 35 seconds, and the failing 3D-Pack accounted for about 10 of those.

The log said why. SAM3 expects a separate isolated environment, found it [MISSING -- run install.py], and fell back to an in-process import. It still works, so nobody noticed. The pack's install step had simply never been run. Sort the import times, look at the top three, and read their log lines. That's usually where a minute of every restart is hiding. It matters more than it sounds if you restart ComfyUI from automation, like the API pipelines in my ComfyUI best practices post, where a slow boot looks exactly like a dead server to anything with a 60-second health check.

1. Search the logs for Cannot import and read the reason after the colon. Check .prev.log too if it only happened once.
2. Many packs, same OSError? Fix how ComfyUI is launched, not the packs.
3. No module named a top-level package?Install the pack's requirements.txt with the exact Python from the log header.
4. No module named a submodule of a library you have? The library moved it. Update or patch the pack, and leave the shared library alone.
5. NameError, AttributeError or SyntaxError in the pack's files?It's a bug. Update, check its issues, or disable it.
6. Restart and count nodes per pack from /object_info. Search for Error importingwhile you're there.

If nothing in the log makes sense, ComfyUI's own docs recommend starting with --disable-all-custom-nodesand then bisecting the folder. That works, but on a box with 70+ packs it's a slow way to learn what one log line would have told you.

How I got these numbers: nine retained startup logs (comfyui*.log plus .prev and .prev2) copied off my Windows ComfyUI server on October 29, 2026, covering boots from May 22 to October 27 on ComfyUI 0.21.1 and 0.33.0, Python 3.13.12. Module paths were checked by importing them in both installed Pythons. Node counts come from the live server's /object_info the same day.