Why are ComfyUI nodes missing?

Find out what is missing

Keep an original workflow copy and read the exact warning. An unknown node type means ComfyUI cannot find the implementation named by the graph. A model dropdown with no matching file is a different problem. Installing a node pack does not supply every model it loads. The model troubleshooting guide distinguishes absent files and incompatible model families.

Write down the node type exactly, your ComfyUI version, installation type and what changed before failure. Preserve the error text and startup log as well as any screenshot. These help distinguish a missing component from an installed component that failed to load.

Check the workflow's source

Return to the tutorial or author's repository. Look for dependencies and expected versions. A label displayed on a node is not always its package name. Identify the repository that provides the node type; do not install the first similarly named package.

Some workflows use recently added core nodes. Others need community extensions. A different model family may need a different graph, not a renamed file. If the source supplies no dependencies, use a documented official example as a starting point instead of guessing through plugins.

Use the right installation and environment

The custom-node installation guide explains two parts: node code and Python dependencies. Follow your installation's instructions. Desktop, portable and manual environments differ; installing a package into an unrelated Python interpreter does not necessarily make it available to ComfyUI.

Where Manager is available, locate the identified package using its current interface. The official Manager repository documents missing-node tools, but labels and registry coverage can differ between versions. Review the package source and requirements first. Automatic discovery does not establish compatibility with your graph.

If it is installed but still missing

Restart the applicable ComfyUI instance and refresh the interface. Inspect startup logs for import failures. A folder on disk proves files exist; it does not prove Python imported them. The dependency guide explains how conflicting requirements and mixed environments can break extensions.

Address the first relevant import error instead of adding unrelated packages. Preserve a working environment before changing versions. If two extensions need incompatible dependencies, a separate environment or simpler graph may be preferable to repeatedly overwriting packages.

Isolate wider breakage

If the interface or a previously working graph broke after an extension change, follow custom-node troubleshooting: temporarily disable extensions and narrow down which change causes the problem. A graph that requires custom nodes will not become executable with all of them disabled; this is diagnosis.

For unresolved cases, collect the workflow, exact versions, first error, operating system and reproduction steps. Remove private media before sharing. This is documentation-based guidance; no particular extension installation or repaired generation has been executed for this page.