ComfyUI IMPORT FAILED: Find the Real Error Fast

The real error is never in the red node — it is the Python traceback ComfyUI printed at startup, on and just above the line that begins Cannot import. The (IMPORT FAILED) text you are staring at is a summary line from ComfyUI's startup timing report, printed long after the actual exception scrolled past. Find that traceback and you have the answer in about ninety seconds. If ComfyUI-Manager is installed, it is already saved to ComfyUI/user/comfyui.log, and the same message is one click away behind the red IMPORT FAILED ↗ button in the Custom Nodes Manager.

First, make sure you have the right failure. If your nodes are red but the console is silent, the pack was never installed and you want ComfyUI missing node types instead. If Manager's Install button does nothing at all on ComfyUI Desktop, that is a third thing again — jump to the Desktop section. The one-line test and the full comparison are in the next section.

This matters because the advice you will find is "reinstall" or "use the portable build," and neither addresses three of the four things that actually cause this. Reinstalling fixes a missing package. It does not fix a wheel compiled against a different torch, it does not fix two nodes demanding incompatible NumPy versions, and it does not fix a node written for a ComfyUI API that no longer exists — it faithfully recreates all three the moment you reinstall the same node set.

For scale: a GitHub issue search run on 2026-08-23 returned 473 issues in Comfy-Org/ComfyUI matching "IMPORT FAILED" and 573 matching "No module named", plus 71 more for "IMPORT FAILED" in Comfy-Org/ComfyUI-Manager. By issue volume it is the most-reported thing that goes wrong in ComfyUI, and almost none of those threads start by reading the traceback.

---

Red Nodes on a Workflow, or IMPORT FAILED in the Console?

These are two different bugs with two different fixes, and picking the wrong one is why people spend an evening pip-installing at a problem that pip cannot touch. The deciding test takes five seconds: look at your startup console.

The rule of thumb: a traceback means installed-but-broken; silence means never installed. A node can also be both — a pack that failed to import is still missing its node types, so the canvas shows red boxes and the console shows a traceback. In that case the traceback is the real fault; fix it and the red boxes resolve themselves.

---

The Three-Minute Triage

Do these three things in order. Step 1 alone resolves most cases, because it turns "IMPORT FAILED" into a named module or a named symbol.

Step 1 — Find the line that starts with "Cannot import"

When a custom node raises during import, ComfyUI's load_custom_node in nodes.py logs the complete traceback first, then a one-line summary:

Cannot import D:\ComfyUI\custom_nodes\some-node module for custom nodes: No module named 'insightface'

The exception message after the colon is your answer. The traceback immediately above it tells you which file and which import statement blew up. Scroll up in the console and search for Cannot import — every failing node produces exactly one, and they appear during startup, not at the end.

The block you probably noticed instead looks like this and comes much later:

Import times for custom nodes:
   0.0 seconds: /home/you/ComfyUI/custom_nodes/websocket_image_save.py
   0.3 seconds (IMPORT FAILED): /home/you/ComfyUI/custom_nodes/some-node

That is a report, generated from a list of already-recorded results. It contains no diagnostic information by design — it exists to tell you which nodes to go look up.

Step 2 — Click the red button in ComfyUI-Manager

Open Manager → Custom Nodes Manager. A node that failed to import renders a red IMPORT FAILED ↗ button next to its title. Clicking it posts to Manager's /customnode/import_fail_info endpoint and opens a dialog headed "Error message occurred while importing the '' module." with the stderr Manager captured for that specific node.

Manager can do this because its prestartup script wraps stdout/stderr at launch and attributes each error line back to the custom node that emitted it. Two consequences worth knowing:

• If the dialog says "The information is not available.", Manager did not capture anything for that node — go to the log file instead.
• Manager also watches for the seconds (IMPORT FAILED): pattern in the startup stream, which is how it knows to draw the button at all.

Step 3 — Read the log file if the console has scrolled or you launched from a shortcut

ComfyUI core does not write a log file unless you ask for one. Its logger accepts a list of file outputs and main.py passes exactly what you gave --verbose; with no --verbose that list is empty. To get one:

# LEVEL then FILE. Console stays at INFO, the file gets everything.
python main.py --verbose DETAIL comfyui.log

# Or crank the console itself to DEBUG with no file:
python main.py --verbose

ComfyUI-Manager, however, logs to a file by default. Its prestartup script tees the whole console into <user_directory>/comfyui.log — that is ComfyUI/user/comfyui.log on a default install — and rotates one generation on each launch (comfyui.prev.log, then comfyui.prev2.log). It prints ** Log path: <absolute path> during startup so you never have to guess. You can turn this off with file_logging = False in Manager's config.ini; if someone did, turn it back on.

That rotation detail is the one that catches people: the log you want is often comfyui.prev.log, because restarting ComfyUI to "check the log" already overwrote the run that failed.

# Linux/macOS — pull every failure reason out of the log in one line
grep -n "Cannot import" ~/ComfyUI/user/comfyui.log

# Windows PowerShell
Select-String "Cannot import" "$HOME\ComfyUI\user\comfyui.log"

---

Reading the Traceback: The Four Failure Classes

Read across the ComfyUI and ComfyUI-Manager issue trackers, import failures sort into four shapes, and each carries a signature string that tells you which one you have. Ordered roughly by how often it turns out to be the real cause.

Class 1 — No module named 'x'

ModuleNotFoundError: No module named 'insightface'
Cannot import /home/you/ComfyUI/custom_nodes/some-node module for custom nodes: No module named 'insightface'

The honest majority case. The node ships a requirements.txt; nobody installed it, or it was installed into the wrong interpreter. Do not guess the package name from the module name — they differ often enough to waste your evening (cv2 comes from opencv-python, PIL from pillow, yaml from PyYAML, git from gitpython). Install the node's own requirements file with the interpreter ComfyUI runs on, using the exact form in the next section:

<your-comfyui-python> -m pip install -r custom_nodes/some-node/requirements.txt

If you installed it and the message is unchanged on the next launch, you did not install it into ComfyUI's Python. That is not a maybe — it is what the message means.

Class 2 — undefined symbol / DLL load failed

The Linux shape (symbol names vary by torch version — this is the pattern, not a literal string to match):

ImportError: /path/to/site-packages/flash_attn_2_cuda.cpython-312-x86_64-linux-gnu.so:
undefined symbol: _ZN3c10<...mangled C++ symbol...>

On Windows the same condition usually surfaces as ImportError: DLL load failed while importing flash_attn_2_cuda: The specified module could not be found.

This is a C++/CUDA extension — flash-attn, sageattention, insightface, xformers, or a node that ships its own kernels — that was compiled against a different torch build than the one currently installed. The mangled _ZN3c10... symbol is a give-away: c10 is PyTorch's core namespace, so the extension is asking libtorch for a function that this libtorch does not export.

The trap: it does not have to be you who changed torch. Installing one node's requirements can silently pull a different torch, which invalidates every other compiled extension in the environment at once. Check what you have before you install anything else:

<your-comfyui-python> -c "import torch; print(torch.__version__, torch.version.cuda)"
<your-comfyui-python> -m pip list | grep -iE "torch|xformers|flash|sage|insightface"

Then reinstall the offending extension against the torch you actually have — for pre-built wheels that means matching the torch version, the CUDA build and the Python minor version. If the extension is CUDA-architecture-specific and you are on an RTX 50-series card, the failure is a related but distinct one; we cover the compute-capability side separately in the CUDA notes below.

Class 3 — the NumPy/protobuf conflict between two nodes

NumPy 2 announces this one in plain English, which is a mercy:

A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.2.6 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.

Here is the sequence that produces it, and it is the single most under-diagnosed thing in ComfyUI: you install node A, its requirements.txt pins numpy<2, pip happily downgrades your NumPy, and node B — which shipped a wheel compiled against NumPy 2 — starts failing on the next launch. Node A works. Node B breaks. You were not touching node B. The same pattern runs with protobuf, transformers, tokenizers, opencv-python and pydantic.

The tell is temporal, not textual: the node that broke is not the node you installed. If a node that worked yesterday is red today and you installed something else in between, this is your class.

# Fast second opinion — catches declared conflicts only (see limits below)
<your-comfyui-python> -m pip check

Class 4 — the node targets an older ComfyUI

ImportError: cannot import name '<some_helper>' from 'comfy.<some_module>'

An unmaintained node reaching into ComfyUI internals that were refactored out. There is no user-side fix beyond updating the node, finding a fork, or removing it. Check the node's repository for recent commits before you spend time on it.

A distinct, easily confused message: if a module imports cleanly but exposes neither of the two entry points ComfyUI accepts, you get

Skip /home/you/ComfyUI/custom_nodes/some-folder module for custom nodes due to the lack of NODE_CLASS_MAPPINGS or comfy_entrypoint (need one).

That is not an import failure — it is a contract failure. It also fires if you git cloned something into custom_nodes/ that was never a node pack, which happens more than people admit.

If you are new to the whole stack, our ComfyUI complete guide covers the install and Manager basics this page assumes.

---

Installing Into the Right Python

"I installed it and it still fails" is nearly always this: three ComfyUI distributions ship three different interpreters, and only one of them is the one your pip is touching.

The portable build

The Windows portable launcher is a one-line batch file: .\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build. Run your pip from the folder that contains python_embeded and ComfyUI — not from inside ComfyUI:

.\python_embeded\python.exe -s -m pip install -r .\ComfyUI\custom_nodes\some-node\requirements.txt

That -s is not decoration. It tells Python to ignore the per-user site-packages directory, which is exactly where a stray pip install from a system Python would have put the package. Keeping -s on your pip call means you are installing where ComfyUI will actually look. ComfyUI-Manager's own portable bootstrap script uses this identical form.

venv installs

The failure mode here is subtler: an activated venv that is not this ComfyUI's venv, or a shell where activation silently did not take. Never trust which python — ask ComfyUI's own interpreter to identify itself:

# Run this with the SAME interpreter you launch ComfyUI with
python -c "import sys; print(sys.executable); print(sys.prefix)"

Then paste that exact path into your pip command as <that-path> -m pip install .... Absolute paths cannot be ambiguous; pip on $PATH can.

The desktop app

The desktop application manages its own environment — on macOS the app itself lives at /Applications/ComfyUI.app while the Python environment and custom_nodes/ sit under ~/Documents/ComfyUI/ — and hand-installing into it is how people end up with a broken app and no obvious way back. Prefer Manager's install button, which installs into the environment ComfyUI is running. If you need pip-level control over your node stack, the portable build or a git clone with your own venv is the appropriate tool — Comfy's own README calls the portable build "not recommended for regular users" for the mirror-image reason.

Desktop also fails in ways the four classes above do not describe, because on Desktop the install itself can never run. That is the next section.

---

Why Does Every Install Fail on ComfyUI Desktop?

If you are on ComfyUI Desktop and every node install fails — not one node, all of them — stop debugging dependencies. Two open ComfyUI-Manager bugs break the install path before pip is ever invoked, and no amount of correct requirements.txt will get past them.

The four classes earlier on this page were written for portable and git-clone installs, where the node reaches disk and then fails to import. Desktop shifted the common failure one step earlier: the node never reaches disk at all. Here is what each Desktop symptom actually is.

The 0ms failure with no error message

This is the one that wastes the most time, because there is nothing to read. Reported against ComfyUI Desktop 0.8.36 on macOS arm64 with Manager V4.2.1, the batch history records the install like this:

{
  "operation_type": "install",
  "result": "failed",
  "error_message": null,
  "start_time": "2026-05-05 13:32:27.652231",
  "end_time": "2026-05-05 13:32:27.652231"
}

Start time equals end time. The operation did not begin — it was refused. The reporter of the companion issue traced the refusal into Manager's legacy/manager_server.py, where local-mode is derived from what the server is bound to rather than who is connecting:

is_local_mode = is_loopback(args.listen)

ComfyUI Desktop listens on 0.0.0.0, so is_loopback returns False, and with the shipped defaults of network_mode = public and security_level = normal the gate rejects the install with HTTP 403 before any git or pip call happens. That is why the UI shows no error: there was no command to fail.

The practical consequences, in the order worth trying:

1. Check Manager's config.ini for security_level. The issue reporters' workaround is weak; understand that you are disabling a guard that exists for remote-exposed installs before you do it.
2. If you can set Manager's listen address to 127.0.0.1, do that instead — it fixes the same condition without weakening the security level.
3. Otherwise git clone the pack straight into custom_nodes/ and install its requirements with the Desktop venv's own interpreter. Manual cloning is confirmed working in the same issue thread while the Manager path is not.

Both issues were open when this page was written. Check them before assuming your install is unusual.

No module named 'comfy' is not your node's error

The other Desktop-era failure looks like a dependency problem and is not one. Manager v4 ships as a pip package in the ComfyUI venv, and when it shells out to its git helper, the helper re-imports the Manager package, which imports ComfyUI:

[!] Traceback (most recent call last):
[!]   File ".../site-packages/comfyui_manager/common/git_helper.py", line 12, in <module>
[!]     from comfyui_manager.common.timestamp_utils import get_backup_branch_name
[!]   File ".../site-packages/comfyui_manager/__init__.py", line 6, in <module>
[!]     from comfy.cli_args import args
[!] ModuleNotFoundError: No module named 'comfy'
[ComfyUI-Manager] Installation failed:
Failed to clone repo: https://github.com/evanspearman/ComfyMath

(Install paths abridged; the full lines in the reports point into the Desktop venv's site-packages.)

Read the file names, not the message. comfy here is ComfyUI's own package, and the file that cannot find it is comfyui_manager/common/git_helper.py — Manager's, running as a subprocess that does not have ComfyUI's root directory on sys.path. Nothing about your node, its requirements.txt or your torch version is involved, so pip install cannot help. Reported on both Windows and macOS Desktop installs, it stops the clone from happening at all, which is why custom_nodes/ stays empty afterwards. Clone by hand until it is fixed upstream.

How to tell this apart from a class-1 failure in one glance: a genuine No module named failure names your node's file in the traceback and appears during startup, after ComfyUI has begun loading custom nodes. This one names a comfyui_manager file and appears when you press Install. Same exception type, opposite fix.

On Apple Silicon, a Desktop install that gets past this point can still fail at runtime on Metal-specific errors rather than imports — those are a separate diagnosis, covered in ComfyUI on Mac: MPS errors and what fixes them.

---

When Node A Breaks Node B

There is no dependency-conflict view in ComfyUI-Manager. What it has instead is three blunt but effective tools, and knowing they exist is worth more than another reinstall.

Read Manager's own configuration surface, because it tells you what the maintainers know goes wrong:

Where these files live depends on your ComfyUI version. Manager's README gives two paths: <USER_DIRECTORY>/__manager/ on ComfyUI v0.3.76 and later (the versions with the System User API), or <USER_DIRECTORY>/default/ComfyUI-Manager/ on older ones — with <USER_DIRECTORY> defaulting to ComfyUI/user unless you passed --user-directory.

pip_auto_fix.list is the one that solves the class-3 loop directly. If node A insists on downgrading your NumPy on every startup and you would rather it lost that argument, put the version you want in that file and Manager restores it each launch. Manager already does exactly this internally for comfyui-frontend-package, which custom nodes clobber often enough that it earned a hardcoded restore.

What pip check catches, and what it cannot

pip check reads installed packages' declared metadata and reports pairs where a requirement is unsatisfied — nodeA-dep 1.2 has requirement numpy<2, but you have numpy 2.2.6. That is genuinely useful for class 3, costs a second, and should be your reflex after any node install. uv pip check does the same job against the same metadata, faster.

What neither can do is see binary incompatibility. A flash-attn wheel compiled against torch 2.7 declares only torch, with no upper bound, so an environment holding torch 2.13 and that wheel passes pip check cleanly and still dies at import with an undefined symbol. That is class 2, and only the traceback finds it. Treat a clean pip check as evidence about metadata, not about your install.

The order of operations that keeps this from recurring

1. Save a Manager snapshot while things work. It is the only cheap undo you have.
2. Install one node at a time and restart. Batch installs make attribution impossible.
3. After each install, run pip check and glance at pip list for a moved torch or numpy.
4. When a previously working node goes red, suspect the last install, not the node.

---

What This Page Cannot Tell You

Some honesty about the edges:

• Node-specific fixes. There are thousands of custom node packs, and their failures are their own. This page is about localising the fault to a named module or symbol in three minutes; after that, the node's own issue tracker — searched for the exact string from your traceback — is a far better resource than any article.
• Whether your specific wheel exists. For compiled extensions the answer is a matrix of torch version, CUDA build, Python minor version and GPU architecture, and it changes weekly. Check the project's releases page for a wheel matching all four rather than trusting a command copied from a forum.
• GPU-architecture failures. If your traceback ends in CUDA error: no kernel image is available for execution on this device rather than an import error, you have a compute-capability problem, not a dependency problem — common on new RTX 50-series cards, where a wheel was built without support for the architecture. Different diagnosis, different fix. Our CUDA optimization guide covers the neighbouring performance-side settings.
• Whether the Desktop bugs are still open. The two Manager install failures described above were open issues when this page was written. If you are reading this later, check the linked threads before adopting a workaround — the security_level change in particular is not something to leave in place after upstream fixes the gate.
• We read this from source, not from a lab. The strings, file paths, flags and endpoints quoted here were verified against the ComfyUI, ComfyUI-Manager and ComfyUI_frontend repositories and their issue trackers on 2026-08-23 (ComfyUI v0.33.1; ComfyUI-Manager at commit head that day). We do not run these installs on our own hardware, so every log line here is quoted from a source, not reproduced by us. Exact wording changes between versions — if a string here does not match your console, trust your console.

If the nodes were never installed in the first place — red boxes, no traceback — the fix is a lookup, not a debug session: ComfyUI missing node types maps each red class_type back to the pack that owns it. When the nodes finally load, the workflows are the fun part: see our ComfyUI FLUX workflow guide, the Z-Image Turbo node setup, or running FLUX on a low-VRAM GPU if your card is the next constraint. For failures outside ComfyUI entirely — services that will not start, ports, permissions — see troubleshooting local AI.

---

Sources

• Comfy-Org/ComfyUI — nodes.py (load_custom_node, init_external_custom_nodes), app/logger.py, comfy/cli_args.py, .ci/windows_nvidia_base_files/run_nvidia_gpu.bat, README. v0.33.1, released 2026-08-13.
• Comfy-Org/ComfyUI-Manager — prestartup_script.py (log path and rotation, per-node stderr capture), js/custom-nodes-manager.js (handleImportFail), glob/manager_util.py (pip_auto_fix.list), README (paths, config.ini).
• ComfyUI-Manager issue #2853 — "Extension install fails instantly (0ms) with no error_message on ComfyUI Desktop macOS". Source of the batch-history JSON and the Desktop 0.8.36 / Manager V4.2.1 environment quoted above.
• ComfyUI-Manager issue #2854 — "Desktop listen address 0.0.0.0 causes is_local_mode=False, blocking all installations". Source of the legacy/manager_server.py security-gate code.
• ComfyUI-Manager issue #2556 and ComfyUI_frontend issue #9204 — the No module named 'comfy' traceback from git_helper.py, reported on Windows and Desktop installs respectively.
• Comfy-Org/desktop issue #1667 — "Reset Environment" does not reinstall custom node pip dependencies. Open at the time of writing.
• ComfyUI issue #12213 — ModuleNotFoundError: No module named 'comfy_aimdo', the core-module variant. Closed.
• ComfyUI_frontend — src/locales/en/main.json, for the current missing-node dialog wording quoted in the disambiguation table.
• GitHub issue search, run 2026-08-23 — issue counts for "IMPORT FAILED" and "No module named" in the ComfyUI and ComfyUI-Manager repositories.
• NumPy — the NumPy 2.x ABI warning text quoted in class 3.
• pip documentation — pip check semantics.

---

FAQ