ComfyUI “Missing Node” and “Import Failed”: A Complete Diagnostic Walkthrough

The Symptom: Red Nodes and a Reload That Never Fixes

You open a workflow you downloaded from Civitai or a friend’s chat, and half the graph is bright red. A banner tells you that nodes are missing, or the ComfyUI Manager reports “Import Failed” in red text next to a plugin name. You click “Install Missing Custom Nodes,” restart, and — sometimes — the red nodes are still there.

This is far and away the most common support complaint in the ComfyUI community. The official troubleshooting guide opens with a blunt statement that most reported issues actually come from custom nodes, not from ComfyUI core. So before you reinstall anything, you need a reliable diagnostic sequence that tells you which of a handful of distinct failure modes you are actually hitting.

The good news is that “missing node” is not a single problem. It is a symptom with a small set of well-understood causes, and each cause has a deterministic fix. This article walks through the diagnostic flow I use on a production ComfyUI install (66 custom node packages, running on an RTX 5060 Ti), with the exact commands and files to check at each stage.

A quick reality check before you start: in many cases the node is not actually missing at all. It is merely failing to load, which ComfyUI reports as “missing” because the name never made it into the node registry. Your first job is to distinguish “not installed” from “installed but failing to import.” These have completely different fixes.

The One Skill That Matters: Read the Actual Error

ComfyUI prints import failures to its console (or terminal). The browser banner only tells you a node is missing — it does not tell you why. The real answer is always in the Python traceback written to the terminal where you launched ComfyUI.

Start ComfyUI from a terminal so you can see that output:

cd ~/ComfyUI
python main.py

Now trigger the failing load (restart, or click “Try fix” in the Manager). Scroll the terminal for a Traceback (most recent call last): block. The final line is the actual error class. Here is what each one means in practice:

• ModuleNotFoundError: No module named 'torchvision' — a Python dependency is missing. The node package installed, but a library it imports is absent or the wrong version.
• ImportError: cannot import name 'X' from 'Y' — a version mismatch: the custom node pins an API that changed in a dependency you have already upgraded.
• OSError ... libcuda.so.1: cannot open shared object file — a native library or GPU driver issue, common on Linux (the official guide lists this under its Linux-specific section).
• SyntaxError / IndentationError — the node code itself is broken for your current Python version; a plugin written for Python 3.10 behaviors can fail on 3.11+.

This single step — actually reading the last line instead of the red banner — resolves a surprising number of cases because it tells you whether to install a pip package, pin a version, or touch nothing and just update the node.

Verify Against the Registry, Not the Workflow File

A workflow JSON stores names like KSamplerAdvanced or VHS_LoadVideo. When ComfyUI loads it, it looks each name up in its live node registry. You can confirm whether a name genuinely exists on your machine by checking the frontend’s object info endpoint:

curl -s http://127.0.0.1:8188/object_info | python3 -c "import sys,json; d=json.load(sys.stdin); print('KSamplerAdvanced' in d, 'LoadImage' in d)"

If a name prints False here, it is categorically not registered — either not installed, or installed but failing to import. If it prints True but the node is still red in the UI, you have a frontend/backend mismatch (the JavaScript side has an old shim), which a browser hard-refresh and a frontend rebuild usually clears.

Diagnosing the Two “Missing” Cases

Case 1: Genuinely Not Installed

The workflow references a node whose package simply is not in custom_nodes/. This is the easy half. You have three install paths:

• Via ComfyUI Manager (recommended): search the node name, click Install, restart.
• Manually via git: cd custom_nodes && git clone <repo-url>, then restart.
• Via git clone + pip install when the node has dependencies: clone, then pip install -r requirements.txt inside the node folder.

On my own install, I run ComfyUI with a dedicated virtualenv (~/ComfyUI/venv, Python 3.11.15 in my case). Whichever install path you use, the dependencies must go into the same environment that runs ComfyUI, or you will get a ModuleNotFoundError the moment it loads.

Case 2: Installed but Failing to Import

This is the case the “Install Missing Custom Nodes” button cannot help, because the folder is already there. ComfyUI scans every directory in custom_nodes/ and tries to import it; an import that throws means the node never registers, and the UI shows it as missing.

The loader logic is worth knowing because it explains a subtle trap. In ComfyUI’s node loader, a folder whose name ends in .disabled is skipped entirely — it is not imported at all. The same loader also consults a manager function (comfyui_manager.should_be_disabled()) to honor nodes you disabled through the Manager UI. This means:

• A folder you renamed to MyNode.disabled to turn it off will show up as “missing” for any workflow that still references it — not because it is broken, but because you (or a previous session) disabled it.
• Leftover junk folders with suffixes like .old-074513 (a timestamp backup pattern) are silently ignored. I actually found one of these on my live machine: a ComfyUI-GGUF.old-074513 directory sitting next to the active ComfyUI-GGUF. It is harmless, but it is also exactly the kind of directory that confuses people about why a node appears in the filesystem yet not in the UI.

To isolate an import failure, disable everything except the problem node and observe. There are a few concrete actions:

• Launch with only core nodes — temporarily move suspect folders out of custom_nodes/, or rename them with a .disabled suffix, then restart. If the crash disappears and comes back when you restore one folder, that folder is the culprit.
• Read the __init__.py traceback — the failing import always prints a stack trace. The offending node folder’s name is usually visible in that trace’s file paths.
• Check for a stale .disabled or .old-* twin — ls -d custom_nodes/*.old* custom_nodes/*.disabled* will reveal leftover folders that may be shadowing the real one in your mental model.

The Manager Itself: A Source of “Import Failed”

One frequently-overlooked cause of “Import Failed” is that ComfyUI-Manager itself is missing or out of date. The red “Import Failed” button people click most often is rendered by the Manager, so if the Manager can’t import the plugin, every plugin it tries to install or enable will report failure downstream.

On my production machine, the Manager is not installed at all (a deliberate choice — I install custom nodes via git and manage dependencies directly in the venv). That is a completely valid setup, but it means:

• There is no “Install Missing Custom Nodes” one-click button; missing-node workflows must be resolved by reading the workflow JSON’s custom_nodes list and cloning those repositories manually.
• The comfyui-manager config directory (user/default/comfyui-manager/) does not exist, so any guide that assumes Manager-side disabling will not map to my environment.

If your Manager shows persistent “Import Failed” for many nodes at once, the highest-value single action is to update the Manager itself (git pull inside custom_nodes/ComfyUI-Manager), then restart. A stale Manager frequently mis-reports import failures for plugins that import perfectly fine.

Verification: When Is It Actually Fixed?

A fix is not complete the moment the red nodes disappear. Confirm at three levels:

• Registry check — re-run the object_info check above and confirm the node name now returns True.
• Fresh generation — run the default workflow (or a minimal graph using just that node) end to end and confirm it executes without a “Prompt execution failed” dialog.
• Console clean — the terminal should show no new Traceback lines on startup. A clean start is the real signal that the import now succeeds.

If you are reporting a bug upstream, the official guide asks for exactly what a good diagnosis already gives you: the full console error, your list of installed custom nodes, the workflow JSON that reproduces it, and the recent changes you made. Gathering those as you go turns a frustrating “it just won’t load” session into a report that can actually be acted on.

Conclusion

“Missing node” and “Import Failed” feel like one problem but are really three: a node that isn’t installed, a node that’s installed but crashes on import, and a node that’s disabled (or shadowed by a stale folder) and thus skipped by the loader. The fix for each is different, which is why blindly clicking “Install Missing” so often fails to change anything.

The discipline that pays off is embarrassingly simple: read the Python traceback in the terminal instead of the red banner in the browser. That one habit moves you from guessing to diagnosing, and it is the reason the official ComfyUI troubleshooting guide and the dedicated custom-node issues page both lead with “rule out custom nodes first.” If you are automating ComfyUI and want the diagnosis-before-queueing mindset baked into a script, the same principle shows up in my earlier walkthrough of submitting and polling ComfyUI’s /prompt API — check what the system actually reports before you assume the model or node is to blame.