ComfyUI Custom Node "IMPORT FAILED"? Read the Traceback, Then Fix It (2026)

By RunAIHome Team · 11 min read
comfyuitroubleshootingcustom-nodespythonlocal-aistable-diffusion

TL;DR: When ComfyUI prints 0.0 seconds (IMPORT FAILED): custom_nodes/<name>, that summary line is useless on its own — the actual cause is the first Python traceback printed above it during startup. Ninety percent of the time it’s one of three things: a missing pip dependency, a NumPy 1.x/2.x clash, or a custom node’s pip install that quietly overwrote your CUDA-enabled PyTorch with a CPU build. Read the traceback, match the error type, apply the matching fix.

What you’ll be able to do after this guide:

  • Find the exact reason a node failed instead of staring at a red node in the canvas
  • Install missing dependencies into the correct Python — the one ComfyUI actually launches with
  • Untangle a NumPy or PyTorch version conflict without nuking your whole install and starting over

Honest take: Don’t reinstall ComfyUI and don’t blindly run “Try Fix” in a loop. Scroll up to the first traceback, read the one line that starts with an error name, and you’ll usually know the fix in 30 seconds.

Step 1: The summary line is a symptom, not the diagnosis

When ComfyUI finishes loading, it prints an import summary for every custom node folder. A healthy node looks like this:

0.4 seconds: /home/user/ComfyUI/custom_nodes/ComfyUI-Manager
1.2 seconds: /home/user/ComfyUI/custom_nodes/ComfyUI-Impact-Pack

A broken one looks like this:

0.0 seconds (IMPORT FAILED): /home/user/ComfyUI/custom_nodes/ComfyUI-ReActor

The reflex is to Google “ComfyUI ReActor import failed” and start trying random fixes. Don’t. That summary line is printed after the failure — it only tells you which node died, not why. The “why” is a full Python traceback printed earlier in the same startup log, the moment ComfyUI tried to import that node’s __init__.py.

So the first move is always the same: scroll up. Ignore the IMPORT FAILED summary at the bottom and scroll back through the console until you find the first block that looks like:

Traceback (most recent call last):
  File ".../custom_nodes/ComfyUI-ReActor/__init__.py", line 1, in <module>
    ...
ModuleNotFoundError: No module named 'insightface'

The last line of that traceback — the one that names an error type — is your diagnosis. ComfyUI’s own troubleshooting guidance says the same thing: the brief IMPORT FAILED notation is intentional, and the real clue is the first genuine traceback above it. Everything below is just matching that error to a fix.

If you’re running the ComfyUI Desktop app and don’t see a console, the startup log lives in the app’s log file (Help → open logs folder), or launch the portable/main.py build from a terminal so you can see stdout. You cannot fix this from the canvas alone — you need the text log.

The one rule that saves the most time

After every change below, fully restart ComfyUI — close the process and relaunch, don’t just refresh the browser tab. Node imports only run at startup. A browser refresh re-fetches the workflow; it does not re-import Python modules. Half the “my fix didn’t work” reports are someone who never restarted the server.

Step 2: Match the error to the fix

Find the error-name line at the bottom of the traceback. It will almost always be one of the following.

ModuleNotFoundError: No module named 'X' — a missing dependency

This is the single most common cause. The node needs a Python package that isn’t installed in the environment ComfyUI is running from. The fix is one line — but it has to go into the right Python.

This is where most people fail. ComfyUI Portable on Windows ships its own embedded interpreter under python_embeded\, and it does not use whatever python your terminal’s PATH points at. If you run a bare pip install insightface, it lands in your system Python, ComfyUI never sees it, and the node fails again on the next launch.

Install into the interpreter ComfyUI actually launches:

# Windows portable build — from the ComfyUI_windows_portable folder:
.\python_embeded\python.exe -m pip install insightface

# Linux / Mac, or any venv-based install — activate the SAME venv ComfyUI uses, then:
python -m pip install insightface

Replace insightface with whatever the No module named '...' line named. Notice the Windows command calls the embedded Python by full path and uses -m pip — that guarantees the package goes where ComfyUI can import it.

Most well-built node packs ship a requirements.txt. If yours has one, install the whole list at once instead of chasing one missing module at a time:

.\python_embeded\python.exe -m pip install -r custom_nodes\ComfyUI-ReActor\requirements.txt

If you’d rather not touch the command line, ComfyUI Manager’s Install Missing Custom Nodes and the per-node Try Fix button both run this same pip install -r requirements.txt against the correct environment for you. Manager is the right first attempt for a missing dependency — just remember to restart afterward.

A module that was compiled using NumPy 1.x cannot be run in NumPy 2.x — a version clash

This one shows up as a wall of text, often ending with the node failing to import torch or cv2. The exact message reads: “A module that was compiled using NumPy 1.x cannot be run in NumPy 2.x as it may crash.” It almost always appears right after you ran ComfyUI’s “update all” or installed a new node pack that bumped NumPy.

What happened: a custom node (or its update) installed NumPy 2.x, but other packages in your environment — frequently an older PyTorch build, OpenCV, or insightface — were compiled against NumPy 1.x. The two ABIs are incompatible, so the compiled module refuses to load.

First, confirm the conflict instead of guessing. pip check reports incompatible pins across the whole environment:

.\python_embeded\python.exe -m pip check
# example output:
# numba 0.59.1 requires numpy<2.1,>=1.22, but you have numpy 2.3.2.

If a package requires numpy<2 and you have a 2.x version, pin NumPy back below 2:

.\python_embeded\python.exe -m pip install "numpy<2"

A specific gotcha: don’t blindly pin an ancient release like numpy==1.23.5. On the Python 3.12+ interpreters that newer ComfyUI builds ship, that old NumPy fails to build because modern setuptools removed the ImpImporter attribute it expects. Use a recent 1.x line that supports your Python — "numpy>=1.26,<2" is the safe range. (Official ComfyUI Portable moved past Python 3.12 in newer builds; v0.3.49 was the last release bundling Python 3.12.10, so check your python_embeded version before pinning.)

The cleaner long-term fix, if your other packages allow it, is to upgrade the NumPy-1.x-compiled package (usually PyTorch) to a build made for NumPy 2.x, rather than holding NumPy back forever. Either direction works — the goal is one consistent NumPy ABI across the environment.

To avoid this entirely next time, preview what a node’s requirements will change before you install:

.\python_embeded\python.exe -m pip install -r requirements.txt --dry-run

If the dry run shows it wants to replace a shared package like NumPy or torch, you’ve found your future breakage before it happens.

AssertionError: Torch not compiled with CUDA enabled — a clobbered PyTorch

If the traceback ends here, a custom node’s install step overwrote your GPU build of PyTorch with the default CPU wheel from PyPI. The node loads, but the moment it touches the GPU, everything downstream dies — and on the canvas it can look like an import failure or a runtime crash.

This is common enough that it gets its own writeup: see ComfyUI “Torch not compiled with CUDA enabled” — every fix that works. The short version: uninstall torch torchvision torchaudio from the embedded Python, then reinstall from the CUDA index (--index-url https://download.pytorch.org/whl/cu128, not --extra-index-url). RTX 50-series Blackwell cards such as the RTX 5090 specifically need the cu128 wheel and PyTorch ≥ 2.7.0, or you’ll trade this error for no kernel image is available for execution.

ImportError: cannot import name 'X' or a bad relative import — a structural problem

If the error names a missing symbol, references __init__.py, or mentions a relative import, the node’s code or folder layout is the problem — not your environment. Two usual causes:

  • You cloned into the wrong depth. A node pack must sit at custom_nodes/SomeNode/__init__.py. If you have custom_nodes/SomeNode/SomeNode/__init__.py (a doubled folder from a clumsy git clone), ComfyUI imports the empty outer folder and finds nothing. Move the inner folder up one level.
  • A partial download. A node pack with many submodules can have one broken file while the rest load — it looks like the package both registered and failed at once. Re-clone it fresh: delete the folder and git clone again, or reinstall via Manager.

SyntaxError / IndentationError — a broken or mismatched node

This means the node’s Python source itself won’t parse — usually because you’re on a ComfyUI or Python version the node doesn’t support yet, or you edited a file by hand. Don’t try to debug registration; fix the source mismatch first. Update the node (git pull in its folder, or Manager → Update), and if it still fails, check the node’s README for the ComfyUI/Python version it requires.

Step 3: When one node breaks, others can too

A subtle trap: when one custom node installs an aggressive dependency pin (say torch==2.4.1) and another needs torch>=2.4.2, installing the second silently changes the version the first one depended on. The first node now imports against a torch it wasn’t built for and starts failing — even though you never touched it. That’s why a single “update all” can break half your nodes at once, as several ComfyUI users reported after a NumPy 2.x bump cascaded through their installs.

The defense is the dry-run habit above plus periodic pip check. When you do hit a cascade, fix the shared package (NumPy, torch) to one version that satisfies the most nodes, rather than reinstalling node by node. If you genuinely need two nodes with irreconcilable pins, the real answer is separate ComfyUI environments — which is exactly the discipline a clean install buys you (see our ComfyUI Windows setup guide and the Linux production setup for environment isolation).

This GPU-vs-environment confusion is the same class of problem that bites Ollama users whose models silently run on CPU — if you’re also wrestling with that, see Ollama not using GPU? Fix CPU-only inference.

A 60-second triage checklist

  1. Launch ComfyUI from a terminal (or open the desktop log file) so you can see startup text.
  2. Find the IMPORT FAILED summary line — note the node name.
  3. Scroll up to the first Traceback block for that node.
  4. Read the last line: ModuleNotFoundError? NumPy 1.x? Torch not compiled? ImportError? SyntaxError?
  5. Apply the matching fix above — into python_embeded\python.exe on Windows portable, or your venv elsewhere.
  6. Fully restart ComfyUI. Re-check the summary.

FAQ

Why does the node show up red in my workflow even after I installed the dependency? A red node means the node type isn’t registered, which happens when import failed. If you installed the dependency but didn’t restart the ComfyUI server (not just the browser), the import never re-ran. Restart the process.

ComfyUI Manager says the node is installed, but it still won’t import. Why? “Installed” in Manager means the files are on disk, not that the import succeeded. The dependencies can still be missing or conflicting. Use Manager’s Try Fix to reinstall its requirements, then read the console traceback if it still fails.

I ran pip install and it said the package is already installed, but ComfyUI still can’t find it. You almost certainly installed into a different Python than the one ComfyUI runs. On Windows portable, you must call .\python_embeded\python.exe -m pip install, not a bare pip. Confirm with .\python_embeded\python.exe -m pip show <package>.

Is it safe to just delete the failing node folder? Yes. Removing a folder from custom_nodes only removes that node pack — your models, workflows, and other nodes are untouched. It’s the fastest way to confirm a single node is the culprit if startup is otherwise broken.

Should I reinstall ComfyUI from scratch? Rarely necessary. A clean reinstall hides the cause instead of teaching you the fix, and you’ll often reintroduce the same conflict the next time you install that node. Read the traceback first; reinstall only if the environment is genuinely corrupted.

Sources

Last updated June 22, 2026. Commands and version numbers reflect ComfyUI builds current as of that date; verify your python_embeded version before pinning packages.

Was this article helpful?