ComfyUI Startup Failed? How to Diagnose and Recover Faster

If ComfyUI will not start at all, do not treat it like a generic install problem.

Most startup failures happen because the environment changed after the original install:

• a plugin modified a critical package
• a binary package no longer matches the runtime
• Torch or CUDA drifted
• a helper file or bootstrap step was removed, blocked, or quarantined

That means the real question is not just "How do I launch ComfyUI?"

The real question is:

"What changed between the last working state and the current broken one?"

What "startup failed" usually means

Startup failure can look like:

• the app window opens, then closes
• ComfyUI never reaches the UI
• the terminal shows an import error before the server starts
• ComfyUI Desktop gets stuck during bootstrapping
• your launcher says a required helper file is missing

Step 1: Classify the startup failure

Before fixing anything, put the failure into one of these buckets.

Category A: Python import failure during startup

Examples:

ModuleNotFoundError: No module named 'cv2'
ModuleNotFoundError: No module named 'onnxruntime'

This usually means a package is missing or broken.

Category B: Core runtime drift

Examples:

Torch not compiled with CUDA
CUDA is not available
AttributeError: module 'torch' has no attribute '...'

This usually means Torch, CUDA, or another critical dependency changed.

Category C: Plugin import chain blocks startup

Examples:

• one custom node fails and startup becomes unstable
• many plugins fail after one install
• the environment worked before a plugin or update

This is where plugin import failures and dependency conflicts overlap.

Category D: Bootstrap or launcher helper failure

Examples:

• a helper executable is missing
• antivirus quarantined a file
• ComfyUI Desktop or another launcher cannot complete the boot sequence

If you see a missing bootstrapper or helper file, check whether antivirus removed it before you reinstall anything.

Step 2: Look for the first real error, not the last visible symptom

Users often copy the last line they see. That is not always the true cause.

Instead, scan the startup log for the earliest failure:

• the first IMPORT FAILED
• the first ModuleNotFoundError
• the first Torch, CUDA, or DLL load error
• the first missing helper or bootstrap file

Everything after that may just be fallout.

Step 3: Use the smallest recovery move that matches the category

If a package is missing

Install only the missing package or the plugin requirements that introduced it.

Do not start with broad upgrades like:

pip install -U everything

That often turns one startup failure into three.

If Torch or CUDA drifted

Treat that as a core runtime problem, not a plugin problem.

Repair the core runtime first, then retest plugin imports.

Common signs:

• ComfyUI falls back to CPU unexpectedly
• CUDA worked before, then stopped after a custom node install
• xformers, onnxruntime, or another package pulled a mismatched build

If a helper or bootstrap file is missing

Check:

• antivirus quarantine history
• install directory integrity
• whether the launcher's helper files still exist

For a concrete example, see Bootstrapper Missing (watchdog_bootstrapper_missing).

Step 4: Avoid the reinstall trap

Reinstalling feels clean, but it is often the most expensive option if you already have:

• downloaded models
• working workflows
• custom nodes you still need
• environment-specific fixes you will have to rediscover

Use reinstall only when:

• the core runtime is too damaged to reason about
• helper files are missing and cannot be restored safely
• repeated package repair attempts caused wider drift

If you still have a recoverable environment, try to preserve it first.

Why startup failures often happen after plugin work

This is the pattern many users miss:

1. ComfyUI starts normally
2. A plugin is installed or updated
3. One requirement changes a core package
4. The next startup fails

That is why startup debugging and plugin debugging are often the same problem seen from two different angles.

A better recovery path than scattered shell commands

The frustrating part is not just the startup failure itself. It is the repair path:

• read a traceback
• try a pip install
• restart
• hit a different failure
• patch another package
• wonder whether you should just reinstall

Wonderful Launcher is meant for that exact phase.

It gives users a more recovery-oriented path when:

• ComfyUI Desktop became fragile after plugins
• a portable environment drifted over time
• you want to preserve existing assets instead of rebuilding from zero

When to switch from self-recovery to expert help

Escalate if:

• startup failure followed multiple plugin repair attempts
• Torch, CUDA, and plugin imports are all failing at once
• you are no longer sure which package or change caused the break
• the environment belongs to a studio or work machine where downtime is expensive

Related guides

• How to Fix ComfyUI Plugin Import Failed Errors
• ComfyUI Dependency Conflicts
• Common Issues
• Troubleshooting Decision Tree

Want the shorter path?

Start with Wonderful Launcher if you want a more guided way to recover. If the environment is still blocked, move to expert help instead of burning more time on blind retries.