ComfyUI Broke After a Python 3.13 Upgrade? The torchvision / sentencepiece Trap and How to Fix It

One of the most confusing ways to lose a working ComfyUI install is not a model or a broken node — it is a Python version bump you did not think about. A routine OS package upgrade, or a freshly reinstalled portable build, silently moves you from Python 3.12 to 3.13. The next time you launch, ComfyUI fails early with a stack trace that ends in ModuleNotFoundError: No module named 'torchvision' — or sentencepiece, or torchaudio, or safetensors. Nothing about your models, workflows, or custom nodes changed, yet the whole thing refuses to start.

This is a documented, recurring failure that has hit the ComfyUI issue tracker repeatedly. It is not a bug in ComfyUI’s own code so much as a collision between a fast-moving Python release and a long tail of C-extension wheels that have not all caught up. This guide walks through the actual error, why it happens, which packages are the usual culprits, and the three fixes that reliably get you back to a working install — without nuking your model folders.

The Symptom: an Early, Misleading Stack Trace

The failure happens at import time, before any model is loaded. A typical report from ComfyUI issue #6169 shows the launch log reporting a healthy-looking environment — pytorch version: 2.5.1+cu124, GPU detected, VRAM total printed — and then dying almost immediately in main.py:

File "/data1/ComfyUI/main.py", line 132, in <module>
    import execution
File "/data1/ComfyUI/execution.py", line 13, in <module>
    import nodes
File "/data1/ComfyUI/nodes.py", line 22, in <module>
    import comfy.diffusers_load
File "/data1/ComfyUI/comfy/diffusers_load.py", line 3, in <module>
    import comfy.sd
File "/data1/ComfyUI/comfy/sd.py", line 10, in <module>
    from .ldm.cascade.stage_c_coder import StageC_coder
File "/data1/ComfyUI/comfy/ldm/cascade/stage_c_coder.py", line 19, in <module>
    import torchvision
ModuleNotFoundError: No module named 'torchvision'

Note the diagnostic trap here: the traceback points at torchvision, but that is usually just the first missing wheel in a longer chain. The same reporter tried to work around it by editing requirements.txt, only to hit torchaudio, then sentencepiece, then kornia, then spandrel one after another. If you fix them one at a time you will chase them forever. The real root cause is the Python interpreter version underneath all of them.

Why 3.13 Breaks It: Python Wheels and C Extensions

ComfyUI is a Python application, and most of its heavy dependencies — PyTorch, torchvision, torchaudio, sentencepiece, and a dozen more — are built as platform-specific, Python-version-specific wheels. A wheel compiled for CPython 3.12 has a filename like torchvision-0.x.x-cp312-cp312-win_amd64.whl. The cp312 tag means it only installs into a Python 3.12 interpreter. When you move to 3.13, pip looks for a cp313 wheel, and for some packages it simply does not exist yet — or exists but only as a source build that requires a compiler you do not have installed.

Two facts make this worse:

• Python 3.13 became the default on newer distros. As project maintainer comfyanonymous noted in the same issue thread, 3.13 is now the stock interpreter on many Ubuntu- and Fedora-based releases shipping in 2025 and later. A clean OS install can land you on a Python that your wheel ecosystem has not fully caught up with.
• Some wheels are effectively unmaintained or compiler-gated. sentencepiece is a recurring example: if a prebuilt wheel is unavailable for your interpreter, installing it from source requires cmake and a C++ toolchain (clang++). Ordinary users do not have that set up, so the install fails cryptically with ERROR: No matching distribution found.

Layer on top of this that individual custom nodes pull their own dependencies. As the official ComfyUI dependencies documentation explains, each custom node ships its own requirements.txt, and some of those packages may only have wheels for 3.12. You can upgrade core ComfyUI cleanly onto 3.13 and still have a specific node fail to import because its dependency is stuck on an older interpreter. That is why “core broke” and “one node broke” show the same symptom: a missing module at startup.

Before You Do Anything: Confirm It Is Really the Python Version

Do not start uninstalling packages. First check what interpreter ComfyUI is actually running and which one your dependencies were installed against.

1. Find the interpreter. For a portable/embedded install, run python_embeded\python.exe --version on Windows, or check the venv you activate before launch. For a manual or Linux install, run which python and python --version from inside the environment ComfyUI uses (the startup log prints the exact Python executable path).
2. Compare to what worked before. If you remember the install working on 3.12 and the interpreter now reports 3.13.x, you have found the root cause. If the version did not change, the problem is more likely a broken dependency or a corrupted environment, and the fixes below will not help — investigate the specific missing module instead.
3. Read the first missing module, then stop. The first ModuleNotFoundError tells you which wheel failed, but remember it is often the head of a chain. Treat it as a signal to inspect the interpreter version, not as an invitation to pip install one thing at a time.

Fix 1 (Safest): Pin or Restore Python 3.12

The lowest-risk fix is to go back to the interpreter your wheel set was built for. The community consensus, visible across the issue thread and the Reddit discussion on Python 3.13 or 3.12 for portable ComfyUI, is that Python 3.12 remains the high-compatibility baseline for the AI ecosystem — especially if you run SageAttention, Nunchaku, or various GGUF/quantization tools whose wheels lag behind.

• On a system you control, reinstall ComfyUI in a fresh directory using a Python 3.12 environment, then reinstall your models and custom nodes. This is the cleanest path and also clears any half-broken dependency state you accumulated while fighting the 3.13 install.
• If your OS auto-upgraded Python (e.g. via pacman, dnf, or apt), pin the package and restore the older interpreter. One Arch user reported fixing the breakage by downgrading back to the prior Python point release and adding IgnorePkg = python to pacman.conf. The exact mechanism varies by distro, but the principle is the same: hold the interpreter until your wheel ecosystem catches up.
• On Windows portable, keep a known-good build. If a portable update lands you on a newer embedded Python, restoring from a backup or downloading a fresh 3.12-based portable release is the fastest fix, since your models/ and custom_nodes/ directories can simply be moved over.

Fix 2: Use pyenv or a Virtual Environment to Isolate the Interpreter

You do not need to downgrade your system Python globally. The cleaner approach is to give ComfyUI its own interpreter with a version you choose, independent of whatever your OS installs by default.

• pyenv lets you install and select a specific Python per directory. The issue #6169 author settled on pyenv with Python 3.11, explaining that a fixed older interpreter “maximizes options” across the whole addon ecosystem. Copy the project, run pyenv install 3.12.x and pyenv local 3.12.x, then reinstall dependencies inside that environment.
• A virtualenv or conda env achieves the same isolation. The key rule — repeated across the community discussion — is to never install ComfyUI and its dependencies into your global Python. Application A needs version X of a library while application B needs version Y; a shared environment guarantees one of them breaks.
• Watch for the stale-interpreter trap. One user reported that even after setting pyenv local 3.11 and seeing * 3.11.11 in pyenv versions, the install still resolved against /usr/lib/python3.13 and failed with ModuleNotFoundError: No module named 'safetensors'. If pyenv does not seem to “stick,” verify which interpreter pip was invoked under (which pip / pip --version) — the shell may be resolving a different pip than the python you selected.

Fix 3: Make 3.13 Work — Only If You Actually Need It

Is 3.13 itself unsupported? Not anymore. ComfyUI’s maintainer noted in early 2025 that ComfyUI had been running well on 3.13 since January, and recent Reddit reports confirm working 3.13.6 installs with PyTorch 2.9, CUDA 12.8, Triton, and SageAttention. The problem is not that 3.13 cannot work — it is that your specific set of wheels and custom nodes may not have caught up yet.

If you genuinely want 3.13 (for example, on a machine where 3.13 is the only interpreter your distro will give you), do the following:

• Install a compiler toolchain (cmake and clang++/build-essential on Linux, MSVC build tools on Windows) so source-build wheels for laggards like sentencepiece can actually compile.
• Install PyTorch-family wheels explicitly from the CUDA index: pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128, matching your CUDA version.
• Treat each custom node as a risk surface. If a single node’s dependency has no 3.13 wheel, that node — not ComfyUI — is what will fail to import. The pragmatic move is to leave that node disabled until its author ships a compatible wheel.

For most day-to-day users, Fix 1 or Fix 2 is the correct call. Chasing 3.13 for the sake of being current usually costs more time than it saves, because the pain is concentrated in the long tail of custom-node dependencies you rely on most.

Common Pitfalls That Make It Worse

• Editing requirements.txt to delete the failing package. Commenting out torchvision, torchaudio, sentencepiece, kornia, spandrel, and soundfile does not fix anything — it just removes the packages the rest of the code expects, guaranteeing a different crash later. This is how the original reporter spent a day and still ended up with a broken install.
• Installing dependencies into global Python. This is the single most common self-inflicted wound. Always isolate.
• Assuming the first missing module is the whole problem. It is the head of a chain. Diagnose the interpreter version, not the individual package.
• Trusting an AI assistant’s blanket claim that a package “can’t be installed” on 3.13. Community reports show Triton and SageAttention can be made to work on 3.13 with the right wheels; the rule of thumb from the thread is that 3.12 + CUDA 12.8 is the high-compatibility path, not that 3.13 is impossible.

How to Verify You Are Actually Fixed

1. Confirm the interpreter first. The launch log should print the Python executable path and a version that matches your target (3.12.x if you pinned). If it still says 3.13.x, your isolation did not take effect.
2. Watch the startup log for a clean import. A healthy launch reaches the model-loading stage and prints your GPU and VRAM totals without a ModuleNotFoundError anywhere above it.
3. Load your heaviest workflow once. The real test is whether your most dependency-laden custom nodes import and run. If a specific node still fails, its requirements.txt is the next thing to inspect.
4. Document the working combination. Note the Python version, PyTorch/CUDA version, and any pinned packages. The next OS-driven Python bump will be a lot less painful if you can reproduce the known-good state.

Conclusion

A Python 3.13 upgrade breaking ComfyUI looks catastrophic but has a boring, well-understood cause: your prebuilt dependency wheels were tagged for 3.12 and stop matching the moment the interpreter changes. The fix is almost never to hunt down each missing module one at a time. Pin or restore Python 3.12, or isolate ComfyUI behind pyenv or a virtualenv so a future OS upgrade cannot silently rip the interpreter out from under it. Check the interpreter version first, keep your models/ and custom_nodes/ intact, and you will be back to generating inside of an hour instead of a day. For more on how ComfyUI fits into a full local generation pipeline, see our guide to the open-source video generation stack on consumer hardware, and if a dependency bump is the least of your worries, our walkthrough of the “No Module Named” error in broken custom nodes covers the node-level variant of this same class of failure.