ComfyUI Missing Node Types: Fix a Red Workflow

A wall of red nodes means the workflow JSON references class_type strings that your install has no Python class for — the pack simply is not there. The fastest reliable fix is to ask the Comfy Registry which pack owns each name: curl https://api.comfy.org/comfy-nodes/FaceDetailer/node returns the pack that provides it, and comfy node install comfyui-impact-pack installs it. ComfyUI-Manager's "Install Missing Custom Nodes" runs the same lookup, but it silently omits any name it cannot resolve, which is why the list is sometimes short or empty.

This is not the same failure as IMPORT FAILED, and the difference decides which page you need. If the pack is not installed at all, you get red nodes and no console traceback — that is this page. If the pack is installed but blew up while loading, ComfyUI prints a Python traceback at startup and Manager shows a red IMPORT FAILED button; the fix is a dependency fix, and that lives in our guide to reading the real error behind ComfyUI's IMPORT FAILED. Check your startup console first. Traceback present means installed-but-broken. Nothing in the console means not installed.

Everything below was read out of source on 23 August 2026: ComfyUI's own execution.py, the frontend's English string table, ComfyUI-Manager's extension-node-map.json, and each pack's NODE_CLASS_MAPPINGS. Where a lookup is wrong, the wrong answer is shown too, because knowing where the tooling misfires is most of the value.

What Does ComfyUI Actually Say When a Node Type Is Missing?

There are two backend errors, they look almost identical, and they mean completely different things. Both come from validate_prompt in execution.py and both carry the type missing_node_type:

Node 'FaceDetailer' not found. The custom node may not be installed.
Node 'ID #98' has no class_type. The workflow may be corrupted or a custom node is missing.

The first one fires when the node has a class_type and that string is absent from nodes.NODE_CLASS_MAPPINGS. That is a genuinely missing pack and it is what this page fixes.

The second fires one branch earlier, when the prompt entry has no class_type key at all. That is not a missing pack — it is a malformed prompt. It usually means you fed the UI workflow format to the API endpoint instead of the API format, or a script built the prompt dict by hand and dropped a field. Installing custom nodes will never fix it. Re-export with Workflow → Export (API) and try again.

On the frontend side the strings you will see are these, quoted from src/locales/en/main.json in ComfyUI_frontend:

That last one catches people constantly on fresh installs. --enable-manager is a real ComfyUI core flag — comfy/cli_args.py describes it as "Enable the ComfyUI-Manager feature." Without it there is no Manager UI and therefore no missing-node installer. The exact pip command in the hint is pip install -U --pre comfyui-manager, read verbatim from MissingNodeCard.vue.

Which Repo Owns Which Node Prefix?

This is the table. Most packs stamp a namespace onto every node they register, so the prefix or suffix in the red node's name identifies the owner outright. Every row below was verified two ways: the node name was read out of that repo's own NODE_CLASS_MAPPINGS (or its node_id declaration, for packs that moved to the newer ComfyExtension API), and then round-tripped through the Comfy Registry's node-name resolver to confirm the install ID.

The right-hand column is what you type. comfy node install PACK_ID takes the Comfy Registry ID, which is frequently not the GitHub repo name — comfy-cli's own README warns that passing repo-name casing fails with Node 'ComfyUI-Impact-Pack@unknown' not found.

Three rows in that table deserve to be pulled out, because they are where people lose the most time.

UltralyticsDetectorProvider is not in Impact Pack. It is the only node in ComfyUI-Impact-Subpack — that repo's __init__.py describes itself as "This extension provides UltralyticsDetectorProvider node", and its NODE_CLASS_MAPPINGS is a one-entry dict. Almost every face-detailing workflow on Civitai needs both packs, and installing Impact Pack alone leaves exactly one node red.

was-ns is the install ID, not was-node-suite-comfyui. The Registry entry for WAS Node Suite points at ltdrdata/was-node-suite-comfyui and describes itself as "A replacement node pack provided for existing users following the retirement of the original author of the widely used WAS Node Suite." If you install the older ID you may get a different tree.

KJNodes has no namespace whatsoever, which is why its nodes are the hardest to identify by eye and the easiest for a lookup to get wrong. That is the subject of the next section.

Why Does "Install Missing Custom Nodes" Find Nothing?

Because two different resolvers sit behind that button, and each fails in its own way. Understanding which one is failing tells you whether to retry, to fix your network, or to give up and install by hand.

Resolver 1 — ComfyUI-Manager's local map. extension-node-map.json is a flat file in the Manager repo listing, for each pack, every node name it registers. At the version committed on 18 August 2026 it holds 5,590 pack entries covering 42,497 node-name entries, of which 40,160 are unique. It is a plain JSON file — you can open it in a browser and Ctrl-F your red node's name, which is the single most reliable manual move on this page.

Resolver 2 — the Comfy Registry API. Manager v4 and the current frontend query registry.comfy.org over the network. That is why Manager issue #2407 is instructive: the reporter's browser console is a wall of Connecting to 'https://api.comfy.org/nodes?node_id=...' violates the following Content Security Policy directive: "connect-src 'self'", plus blocked Algolia search calls. Every request blocked, so Manager showed nothing and looked broken. If your Manager panel is empty rather than wrong, open the browser console before you touch anything else — a CSP rule, a corporate proxy or an offline machine produces exactly this symptom.

The third failure mode is the honest one: the pack is simply not registered. Issue #3138, open since 6 August 2026, asks for precisely this to be surfaced, noting that today "the Install Missing Custom Nodes feature does not detect it" and "there is no indication whether the node pack is unavailable, the workflow is outdated, the node names have changed, or the node pack simply isn't included in the registry." The requester's summary of the consequence matches the forum posts exactly: "users often have to manually search GitHub or ask the community to identify the missing repository."

Manager itself is on 4.2.2 on PyPI, and the frontend refuses to talk to older builds with the message "Please upgrade ComfyUI-Manager to version 4.2.1 or higher. • Desktop: Update the ComfyUI Desktop app • Standalone: Run pip install -U comfyui-manager and restart". If you are seeing that, upgrade before debugging anything else.

How Do I Look Up a Node Name That Is Not in the Table?

There is a single-purpose endpoint for exactly this, and almost nobody knows it exists. The frontend's comfyRegistryService.ts exposes inferPackFromNodeName, which hits /comfy-nodes/{nodeName}/node. You can call it yourself:

curl "https://api.comfy.org/comfy-nodes/UltralyticsDetectorProvider/node"

That returns the pack object, whose id is what you feed to comfy node install. URL-encode spaces and brackets and it handles namespaced names fine — Primitive%20integer%20%5BCrystools%5D resolves to ComfyUI-Crystools, and Power%20Lora%20Loader%20(rgthree) resolves to rgthree-comfy.

When more than one pack registers the same name, the service's own documentation lists the tie-break order: a preemption match against the pack's preempted_comfy_node_names array first, then lower search_ranking values, then higher total installs as the final tiebreaker.

When nothing matches you get an HTTP 404 with this body, which is worth recognising:

{"error":"","message":"No node found containing the specified ComfyUI node name"}

A 404 here does not always mean "obscure pack". Three quite different things produce it:

• It is a core node. KSampler returns 404, because core nodes are not registry packs. If your core nodes are red, no install will help — see the "missing core nodes" toast above, and check that the backend actually started.
• It is a frontend-only node. Reroute returns 404 because it is registered in JavaScript by the frontend, not by any Python pack.
• The pack exists but its node names are not indexed. CR Image Output returns 404 even though ComfyUI_Comfyroll_CustomNodes is a listed pack. Use the prefix table above, or grep extension-node-map.json, and install by pack ID directly.

Do not skip the prefix table in favour of the endpoint, though. Read the next section for why.

Which Node Names Does the Automatic Lookup Get Wrong?

Roughly one node name in twenty-two is claimed by more than one repository. Counting duplicates across extension-node-map.json: of the 40,160 unique node names, 1,814 — about 4.5% — appear under two or more packs. Forks re-declare their parent's node names, aggregator packs re-export other people's nodes, and generic names collide by accident.

Here is what that looks like for names you are actually likely to hit, with every claimant listed:

When Manager offers you a pack you have never heard of for a node you know is standard, this is why. Check the suggestion against the prefix table before you click install, because installing an aggregator pack to get one node drags in its whole dependency tree — and dependency trees are how you end up on the IMPORT FAILED page next.

Two structural quirks make specific packs worse than the averages suggest:

Pattern-matched packs carry few or no explicit names. Only 39 of the 5,590 entries declare a nodename_pattern regex instead of listing node names. Crystools is the extreme case: it lists zero node names and relies entirely on the pattern \[Crystools\]$. Inspire Pack uses Inspire$, rgthree uses \(rgthree\)$, tinyterra uses ^ttN , MTB uses \(mtb\)$. An exact-name grep of the file will miss all of them — which is a fine reason to trust the prefix table over a text search.

JavaScript-only nodes are invisible to every Python-side scanner. SetNode and GetNode — the wireless-link nodes that appear in a huge number of shared workflows — are registered client-side in KJNodes via LiteGraph.registerNodeType("SetNode", SetNode) in web/js/setgetnodes.js. They have no Python class, so they are in no NODE_CLASS_MAPPINGS and no map file. The registry resolver does not fail cleanly on them either: querying /comfy-nodes/SetNode/node today returns an unrelated pack called promptmodels. If your workflow is red on SetNode or GetNode, install comfyui-kjnodes and ignore whatever the resolver suggested.

What Is the Fastest Way to Install Everything a Workflow Needs?

Skip the per-node hunt entirely: both CLIs can read the workflow file and resolve its dependencies for you. This is the single biggest time-saver on this page and it is barely documented.

With comfy-cli, one command installs the lot:

comfy node install-deps --workflow=my-workflow.json

It accepts a .png as well as a .json, so you can point it straight at an image you downloaded with the workflow embedded in its metadata.

If you want to see the resolution before it installs anything — which you should, given the collisions above — generate the dependency file first:

comfy node deps-in-workflow --workflow=my-workflow.json --output=deps.json

The same command exists in Manager's own CLI, which runs without launching ComfyUI at all:

python cm-cli.py deps-in-workflow --workflow my-workflow.json --output deps.json

Read cm-cli.py and you can see exactly what you get back: an object with a custom_nodes map, where each resolved pack carries a state from simple_check_custom_node, and a separate unknown_nodes list. That second key is the answer to the question the GUI refuses to answer. Anything in unknown_nodes is a name Manager could not attribute to any pack — those are your manual installs, and now you have their exact names instead of a red rectangle.

Then install the resolved set:

comfy node install-deps --deps=deps.json

How Do I Install a Pack by Hand When Nothing Resolves It?

Clone into custom_nodes, install its requirements with the same Python that runs ComfyUI, restart. That is the whole procedure, and the only step people get wrong is the second one.

cd ComfyUI/custom_nodes
git clone https://github.com/ltdrdata/ComfyUI-Impact-Subpack
cd ComfyUI-Impact-Subpack
pip install -r requirements.txt

On the Windows portable build that pip is the wrong Python. The portable launcher runs .\python_embeded\python.exe -s ComfyUI\main.py, and the -s flag blocks user site-packages, so anything you installed with a system Python is invisible to it. From the folder containing python_embeded, use:

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

Manager's own installation notes are blunt about directory layout, and the same rules apply to any pack you clone by hand: the pack must sit at ComfyUI/custom_nodes/PACK_NAME, not unzipped directly into custom_nodes, not nested as custom_nodes/PACK_NAME/PACK_NAME, and not left with a -main suffix from a GitHub ZIP download. A pack in the wrong place "may operate, but it won't be recognized within ComfyUI-Manager, and updates cannot be performed." If you are unsure what your directory layout is supposed to look like in the first place, the install section of our complete ComfyUI guide lays it out.

After a restart, watch the console. If the node is still red but now there is a traceback, you have converted a missing-node problem into an import problem — that is progress, and it is handled in the IMPORT FAILED triage guide. If the console instead says the module was skipped for lacking NODE_CLASS_MAPPINGS, the pack is too old for your ComfyUI and needs an update from its author.

What If the Node Type Genuinely No Longer Exists?

Some red nodes cannot be installed, because the pack that provided them renamed or removed them. Shared workflows outlive the packs they were built on, and a two-year-old Civitai download can reference node names that no current release registers.

The tell is a resolver that finds the pack but not the node: extension-node-map.json has no entry, the registry endpoint 404s, yet the pack is clearly installed and its other nodes are fine. In that case you are not missing software — you are holding an obsolete workflow.

The current frontend has a path for this. Its node-replacement flow says "You must install these nodes or replace them with installed alternatives to run the workflow ... Some nodes cannot be swapped and must be installed via Node Manager," and reports back "Replaced {count} node type(s)" when a swap succeeds. Where a swap is offered, take it. Where it is not, open the pack's repo, find the current equivalent node, and rewire that section by hand — usually a rename, occasionally a split into two nodes.

Two related situations that look the same and are not: a node greyed out rather than red is usually a bypassed or muted node, not a missing one; and a workflow that loads fine but errors on queue is a validation problem, not an install problem. If it loads and then dies partway through generation, our guides to ComfyUI out-of-memory errors after an update and black image output cover the two most common causes.

Honest Limitations

• The counts move. 5,590 pack entries, 42,497 node-name entries, 40,160 unique names and 1,814 duplicated names were computed from the copy of extension-node-map.json committed on 18 August 2026. A bot updates that file continuously. Recompute rather than cite this page if the exact number matters to you.
• The "one you almost certainly want" column is a judgement, not a measurement. It reflects which repo actually authored the node, read from that repo's own mappings. It is not a popularity ranking and we did not benchmark the alternatives.
• Registry resolutions were checked once. SetNode returning promptmodels and CR Image Output returning 404 were the live responses on 23 August 2026. The registry is a moving database; re-run the curl before you conclude anything.
• This table cannot be exhaustive. There are thousands of packs. The rows here are the namespaces that show up in widely shared workflows; for anything else, the lookup endpoint and the map file are the general-purpose tools, and the whole point of the section above is teaching you to use them.
• We did not install and run every pack listed. Ownership was verified from source — NODE_CLASS_MAPPINGS dictionaries and node_id declarations — and from the Registry API, not from a local ComfyUI install of all twenty-six packs.

FAQ

What does "the following node types were not found" mean?

That the workflow JSON contains class_type values your ComfyUI has no registered Python class for. The pack that provides those nodes is not installed. It is not a corrupt file, a bad download or a version mismatch in most cases — it is a straightforward missing dependency, and every missing name maps to exactly one pack you can install.

Why does ComfyUI-Manager show fewer missing nodes than I see on the canvas?

Because it silently omits names it cannot attribute to a known pack. Manager issue #3138 is an open request to change exactly that behaviour, noting that there is currently "no indication whether the node pack is unavailable, the workflow is outdated, the node names have changed, or the node pack simply isn't included in the registry." Run cm-cli.py deps-in-workflow instead — it returns an explicit unknown_nodes list.

How do I find out which repo a specific node belongs to?

Three ways, cheapest first. Match the prefix or suffix against the table on this page. Query https://api.comfy.org/comfy-nodes/NODE_NAME/node and read the id field. Or open ComfyUI-Manager's extension-node-map.json in a browser and search for the name — it lists every node each pack registers.

Is this the same as the red IMPORT FAILED nodes?

No, and it is the most common mix-up. IMPORT FAILED means the pack is installed and crashed while loading, so ComfyUI prints a Python traceback at startup. Missing node types means the pack is not installed and there is no traceback at all. Check the startup console: a traceback sends you to the IMPORT FAILED guide, silence keeps you here.

Why did Manager install a pack I have never heard of?

Because node names collide. About 4.5% of the unique node names in Manager's map are claimed by two or more repositories, since forks and aggregator packs re-declare other people's nodes. UnetLoaderGGUF alone is claimed by four. Check the suggestion against the prefix table before installing, and prefer the pack that actually authored the node.

My nodes are red but the missing-node dialog is empty. What now?

Open your browser's developer console. Manager v4 resolves packs over the network against api.comfy.org, and if those requests are blocked — by a Content Security Policy, a proxy, or having no internet at all — you get an empty panel rather than an error. That is the failure documented in Manager issue #2407. Also confirm ComfyUI was started with --enable-manager; without it there is no installer to populate.

Do I need both Impact Pack and Impact Subpack?

For most face-detailing workflows, yes. UltralyticsDetectorProvider lives in ComfyUI-Impact-Subpack — it is the only node that repo registers — while FaceDetailer, SAMLoader and the pipe nodes live in ComfyUI-Impact-Pack. Install comfyui-impact-pack and comfyui-impact-subpack together.

Sources

• ComfyUI — execution.py (validate_prompt: the missing_node_type error messages) and comfy/cli_args.py (--enable-manager)
• ComfyUI_frontend — src/locales/en/main.json (dialog strings), src/services/comfyRegistryService.ts (inferPackFromNodeName, tie-break order), src/components/rightSidePanel/errors/MissingNodeCard.vue (pip command and flag)
• ComfyUI-Manager — extension-node-map.json (node-name to repo map; counts computed from the 18 Aug 2026 commit) and cm-cli.py (deps-in-workflow)
• Comfy Registry / api.comfy.org (pack IDs and the /comfy-nodes/{name}/node resolver) and comfy-cli (node install, install-deps)
• ComfyUI-Manager issues #3138 (unresolvable packs are omitted silently) and #2407 (registry calls blocked by CSP)
• Node ownership read from each pack's own NODE_CLASS_MAPPINGS or node_id declarations, including ComfyUI-Impact-Subpack and ComfyUI-KJNodes (web/js/setgetnodes.js)