ComfyUI Dependency Conflicts: Fix Without Reinstalling

If you searched comfyui dependency conflicts, custom node broke environment, pip install broke comfyui, or a Manager/plugin error that started after installing nodes, the short answer is this:

do not reinstall first. Identify which plugin import or package change broke the environment, then repair the smallest possible layer.

Dependency conflicts are the hidden killer of many ComfyUI environments. A plugin installs a package, that package changes PyTorch, NumPy, OpenCV, or another shared library, and suddenly a workflow that worked yesterday no longer runs.

The expensive part is not just the broken package. It is the recovery loop:

• read logs
• try random pip install commands
• restart ComfyUI
• break something else
• wonder whether you now have to reinstall everything

This guide teaches you how to diagnose, fix, and prevent these issues without treating reinstall as the default answer.

Conflict patterns worth recognizing early

These signatures show up often enough that they are worth recognizing on sight:

Fast Answer

Frequent Conflict Signatures

Recent support cases show that users often search the exact package name from pip check, not the abstract phrase "dependency conflict." These examples are useful because they point to the package family that changed the shared environment.

The important pattern is the same across all of these: a pip check line is a clue, not automatically a command. First confirm whether ComfyUI fails, which plugin failed to import, and whether the workflow you need actually uses that package.

Before You Install Anything Else

Do these four things first:

1. Record the exact error from the startup terminal.
2. Record which plugin or requirement you installed last.
3. Confirm which Python actually launches ComfyUI.
4. Check whether the failure is a core runtime break, a plugin import break, or only a harmless declaration warning.

That order saves a lot of wasted repair work.

A practical triage order

When the environment worked before and then broke after plugin work, this order is usually safest:

1. Check IMPORT FAILED
2. Run pip check in the real ComfyUI Python
3. Decide whether the issue is a hard blocker or soft drift
4. Protect Torch/CUDA before touching plugin packages
5. Fix the narrowest package set possible

Understanding the Problem

ComfyUI plugins are independent Git repos, each with their own requirements.txt. When you install many plugins, their dependency declarations can conflict:

• one plugin expects numpy>=2
• another old plugin only works with numpy<2
• a video node wants a newer transformers
• a face or pose node pulls OpenCV, ONNX Runtime, or native Windows wheels
• an acceleration package expects a specific Python, PyTorch, CUDA, or GPU architecture

The important part is the chain:

1. A workflow asks for backend node classes.
2. Custom node plugins register those classes during startup.
3. Plugin imports depend on Python packages and native wheels.
4. Native wheels may depend on Python, PyTorch, CUDA, cuDNN, GPU architecture, and Windows runtime libraries.

If you fix the wrong layer, the environment gets dirtier while the original problem stays.

Most failed repairs happen because users jump from the visible symptom straight to random package installs without deciding which layer is actually broken.

Step 1: Diagnose

Check for Import Failures

Look at the ComfyUI startup log for lines containing IMPORT FAILED:

IMPORT FAILED: ComfyUI-ExampleNode
ModuleNotFoundError: No module named 'somepackage'

This tells you which plugin failed and why. See the Troubleshooting Decision Tree for a systematic way to classify these errors.

Check with pip

Run pip check in the same Python environment that starts ComfyUI:

Example output:

some-plugin 1.0 requires numpy<2, but you have numpy 2.4.4
another-package 2.0 requires pillow<11, but you have pillow 12.2.0

Check Manager's Failure Info

If ComfyUI is running, visit:

http://127.0.0.1:8188/v2/customnode/import_fail_info_bulk

This returns a JSON list of which plugins failed to import and why.

Step 2: Classify the Problem

Not every pip check warning is a real problem. Classify each issue before installing anything.

Hard Blockers

Fix these first:

• torch mismatch or CPU-only Torch. If ComfyUI reports Torch not compiled with CUDA enabled, use the Torch CUDA repair guide before changing plugin packages.
• A missing package that a plugin directly imports and that plugin is needed by your workflow.
• A native wheel import failure such as DLL load failed while importing cv2.
• Two required plugins needing non-overlapping versions of the same package.

Soft Drift

Monitor these instead of rushing to change the environment:

• pip check reports a version declaration mismatch, but ComfyUI starts, the plugin imports, and the workflow runs.
• A package is only needed by a feature your workflow never uses.
• An optional acceleration backend is missing, but the node has a normal PyTorch fallback.

Rule of thumb: if ComfyUI starts, the plugin registers, and your workflow runs, do not "fix" the warning just to make pip check look pretty.

Declaration Errors

Sometimes plugin authors make mistakes in dependency files:

• typos such as libros instead of librosa
• broad pins that downgrade core packages
• optional packages listed as mandatory
• packages that are correct on Linux but wrong on Windows

Do not edit random plugin source files as the first response. Document the workaround and keep the fix as narrow as possible.

Step 3: Fix

Rule 1: Protect Your Core Runtime

These packages must not be accidentally changed by a plugin install:

Before installing plugin requirements, preview what will change:

python -m pip install -r requirements.txt --dry-run

If the dry run wants to replace Torch, NumPy, Pillow, OpenCV, or the Hugging Face stack, stop and decide whether that plugin really needs those changes.

Rule 2: Use the Correct Python

Plain pip install is risky because it may target the wrong Python.

Rule 3: Use Minimal Fixes

Do not do broad upgrades:

# Risky: upgrades a shared package stack without knowing the impact
python -m pip install -U transformers diffusers huggingface-hub

Prefer the narrow fix tied to the exact failing import, or follow the plugin author's tested compatibility table.

One of the fastest ways to make ComfyUI worse is to run a broad upgrade command against the whole Hugging Face or image stack just because one plugin failed.

Rule 4: Use the Correct Package Name

Some errors look obvious but have package-name traps:

Rule 5: Use Pre-built Wheels for Native Packages

For packages that need compilation on Windows, use a wheel that matches your environment:

• Python version, such as cp312
• PyTorch version, if the wheel is tied to Torch
• CUDA version, if the package includes CUDA kernels
• Windows architecture, usually win_amd64

This applies to packages such as nunchaku, insightface, some attention kernels, and other native acceleration libraries.

What Usually Makes Dependency Conflicts Worse

Avoid these moves unless you have already classified the problem:

• reinstalling random packages from old Reddit or Discord messages
• using plain pip install against the wrong Python
• letting a plugin downgrade Torch without noticing
• upgrading numpy, opencv, transformers, or diffusers as a group without checking impact
• trying to fix a Windows Triton error with the normal upstream triton package
• treating every pip check warning like a production outage

Common Conflict Recipes

Hugging Face Stack Drift

Problem: diffusers, transformers, huggingface-hub, and accelerate usually need to stay in a compatible set.

Safer fix: Do not blindly upgrade one package. Check the plugin README or error log, then install the smallest compatible set in ComfyUI's Python environment.

NumPy 2.x vs 1.x

Problem: Some old plugins still expect NumPy 1.x behavior, while newer packages and current portable environments can run with NumPy 2.x.

Safer fix: Do not globally downgrade NumPy just because an old guide recommends a NumPy 1.x pin. First confirm a real NumPy error from the plugin you need. If the plugin truly requires NumPy 1.x, isolate that workflow in a separate environment or downgrade only after you understand what other plugins will be affected.

OpenCV Package Conflicts

Problem: opencv-python, opencv-python-headless, opencv-contrib-python, and opencv-contrib-python-headless all provide the cv2 namespace. Installing multiple flavors can overwrite files and cause import failures.

Safer fix: Keep one flavor. For most ComfyUI background processing, opencv-python-headless is the safer default. See OpenCV (cv2) Missing or Conflicting.

Nunchaku Wheel Mismatch

Problem: Nunchaku is tied to hardware, Python, PyTorch, CUDA, and the ComfyUI-nunchaku plugin flow. A wheel for the wrong Python or Torch version will not fix the import.

Safer fix: Use Nunchaku's install workflow or a wheel that matches your exact environment. On ComfyUI portable, install with the Python executable that ComfyUI actually prints in its startup log. If the visible workflow symptom is NunchakuFluxLoraLoader, NunchakuFluxLoraStack, or NunchakuFluxDiTLoader, fix the ComfyUI-nunchaku import first instead of installing a package named after the node.

MMCV Build or Wheel Failure

Problem: MMCV can require OpenMMLab wheels that match your Python, PyTorch, CUDA, and platform. If the installer falls back to a source build on Windows, pip install mmcv can fail before the custom node ever imports.

Safer fix: Decide whether the plugin needs full MMCV CUDA ops or only mmcv-lite. See ComfyUI MMCV Install Failed.

ONNX Runtime GPU Mismatch

Problem: onnxruntime-gpu can fail when its CUDA/cuDNN major version does not match the PyTorch runtime stack.

Safer fix: CPU onnxruntime is enough for many pose/face helper workflows. Only install GPU ONNX Runtime when you need it and can match the CUDA/cuDNN family. See ONNX / ONNXRuntime Missing in ComfyUI.

Recovery: When Your Environment Is Broken

If a bad install has already corrupted your core packages, do not guess a universal version set.

1. Record the current Python path, ComfyUI version, PyTorch version, CUDA version, and the last plugin installed.
2. Restore Torch using the Torch CUDA repair guide for your GPU and install type.
3. Repair ComfyUI's own requirements in the same environment.
4. Restart ComfyUI and confirm /system_stats works.
5. Add plugin repairs one at a time, checking IMPORT FAILED after each change.

For the official Windows portable package, this usually means running commands from the extracted portable package root, not from inside the ComfyUI subfolder.

If PyTorch and CUDA still work but ComfyUI core packages are missing, use Repair Broken ComfyUI Portable Dependencies Without Reinstalling Torch before running broad commands that may replace the GPU stack.

When to stop fixing and split environments

Sometimes the real answer is not "one more pip command."

Consider separate environments when:

• one old plugin and one new plugin require non-overlapping package versions
• one workflow needs legacy NumPy / OpenCV pins and another needs newer model stacks
• a video or acceleration plugin keeps forcing core runtime changes

That is usually cheaper than keeping one shared environment permanently unstable.

Start Fresh Only When Recovery Is Too Risky

If the environment is too damaged to recover:

1. Keep a copy of workflows, models, and custom_nodes.
2. Re-extract from the Portable Package or re-run the Desktop installer.
3. Reinstall plugins one at a time, checking after each (see Custom Nodes).

FAQ

What is a dependency conflict in ComfyUI?

It is when one plugin, package, or wheel changes a shared dependency in a way that breaks another plugin, the ComfyUI runtime, or your workflows.

Should I reinstall ComfyUI right away?

Usually no. First identify whether the break is in Torch, a plugin import, a native wheel, or only a version declaration mismatch.

What command should I run first?

Run pip check in the same Python environment that launches ComfyUI, then compare that with the actual IMPORT FAILED lines in the startup log.

Why did one custom node break unrelated workflows?

Because many plugins share the same Python environment and package stack. A change meant for one node can replace core packages used by many others.

How Wonderful Launcher helps

Wonderful Launcher can detect and fix this issue automatically. It manages your ComfyUI environment safely — isolating dependencies, recovering broken installations, and preventing conflicts.

Download Wonderful Launcher — it's free.

A better option than repeating the same repair loop

If dependency conflicts are becoming a recurring maintenance problem, the bigger issue is usually not one package. The bigger issue is that your environment has no recovery-oriented workflow.

Wonderful Launcher is designed for users who need a more stable way to recover existing ComfyUI environments, especially after plugin installs and startup failures. If the environment is already too messy for self-repair, expert help becomes the faster fallback.

Related Guides

• Repair Broken ComfyUI Portable Dependencies Without Reinstalling Torch
• ModuleNotFoundError: No module named 'sqlalchemy' in ComfyUI
• ComfyUI No Module Named 'sageattention'
• ComfyUI Triton Missing or Unavailable
• ComfyUI Nunchaku Missing
• ComfyUI MMCV Install Failed
• ComfyUI Frontend Package
• ComfyUI Torch Not Compiled With CUDA Enabled
• Plugin Management
• Workflow Environment Setup
• Troubleshooting Decision Tree
• Common Issues

Need Help?

Dependency conflicts in multi-plugin ComfyUI environments are our specialty. If you're stuck in dependency hell, try Wonderful Launcher first to recover the environment without reinstalling.

Source References

• Official ComfyUI custom node troubleshooting
• Official ComfyUI model troubleshooting
• Official ComfyUI portable Windows guide
• Official ComfyUI update guide