ComfyUI “No Module Named” After pip install: The Two-Python Trap (venv vs python_embeded)

The Symptom: You Installed It, But ComfyUI Still Says “No Module Named”

You find a custom node on GitHub, follow the README, open a terminal, and run pip install some-package. The install completes with a green “Successfully installed” message. You restart ComfyUI, reload your workflow, and the node still fails with the same red error: ModuleNotFoundError: No module named 'some_package'.

It feels like gaslighting. The package is clearly on your machine—you just watched pip download and install it. The reason it still fails is almost never the package itself. It’s that the python (or pip) you ran in the terminal is not the same Python interpreter that ComfyUI actually uses. ComfyUI runs in an isolated environment, and every custom node executes inside that same environment. Install into the wrong interpreter and nothing changes inside ComfyUI, no matter how many times you reinstall.

This article walks through how to find out which Python ComfyUI is really using, how to install a dependency into the right one, and how to prove the fix worked. The steps are grounded in a real Linux setup I maintain, where this exact two-Python trap bites on a regular basis.

Why There Are Two (or More) Pythons on Your Machine

ComfyUI does not run on your operating system’s default Python. Since the project pulls in high-memory native libraries—PyTorch, CUDA, and friends—it deliberately isolates itself so those dependencies don’t fight with anything else you have installed. Depending on how you installed ComfyUI, that isolation takes one of a few concrete forms:

• Portable (Windows): ships a self-contained python_embeded folder, typically at ComfyUI_windows_portable\python_embeded\python.exe.
• Manual / comfy-cli install: creates a venv (Python virtual environment) or conda env, often at ComfyUI/venv/bin/python or inside a conda env named something like comfyenv.
• Desktop app: manages its own bundled Python per-instance, so there is no separate interpreter for you to target at all.

The official manual install guide is explicit about why this matters: a virtual environment prevents ComfyUI’s dependencies from conflicting with other system packages. There is a direct consequence users often miss, spelled out in the dependencies documentation: every custom node’s requirements.txt must be installed into ComfyUI’s own Python, not the default one on your PATH.

Concrete Evidence From a Real Install

On my own server, the mismatch is easy to reproduce. The system-wide interpreter is Python 3.12:

# which python3
/usr/bin/python3
# python3 --version
Python 3.12.3
# python3 -c "import torch; print(torch.__version__)"
2.13.0+cu130

But the ComfyUI process was launched with a completely different interpreter inside a virtual environment:

# ps aux | grep main.py
... /home/kings/ComfyUI/venv/bin/python /home/kings/ComfyUI/main.py --listen 0.0.0.0 --port 18188

# /home/kings/ComfyUI/venv/bin/python --version
Python 3.11.15

# /home/kings/ComfyUI/venv/bin/python -c "import torch; print(torch.__version__, torch.version.cuda)"
2.12.0.dev20260407+cu128 12.8

These are two genuinely different torch builds on the same machine: system Python has 2.13.0+cu130 while the venv has 2.12.0.dev+cu128. Run pip install some-package in a plain terminal and it lands in /usr/local/lib/python3.12/dist-packages. ComfyUI, however, only ever imports from /home/kings/ComfyUI/venv/lib/python3.11/site-packages. The two never touch. Every “installed but still missing” error on a venv or portable install is this exact split.

Step 1: Find the Python ComfyUI Actually Uses

Before installing anything, identify the interpreter ComfyUI was started with. The most reliable signal is the running process, not whatever python happens to be on your PATH.

On Linux / macOS

ps aux | grep "[m]ain.py"

The first token of the result is the interpreter. If it’s /path/to/ComfyUI/venv/bin/python, you have a venv. If it’s a conda path like /home/user/miniconda3/envs/comfyenv/bin/python, you have conda. If it’s a bare python3 or /usr/bin/python3, ComfyUI is running on your system interpreter (unusual for manual installs, but possible).

On Windows (Portable)

The portable build won’t typically show a separate PATH-based python. Instead, check for the python_embeded folder:

dir ComfyUI_windows_portable\python_embeded\python.exe

If that file exists, it is the interpreter—not the python in your C:\Python3xx or whatever else is on your PATH.

You can also make ComfyUI tell you directly. A one-liner that prints the live interpreter avoids all guessing, and works regardless of OS:

import sys; print(sys.executable)

Run it from inside ComfyUI itself (for example, via a quick temporary custom node or the Python console in some builds) and it prints exactly which binary is executing your nodes.

Step 2: Install Into the Right Environment

Once you know the interpreter, install the missing dependency with that Python’s -m pip. The -m pip form is important: it guarantees the pip you invoke belongs to the exact interpreter you named, rather than depending on whichever pip script your shell resolves first.

Venv (manual / comfy-cli install)

# Linux / macOS
/home/kings/ComfyUI/venv/bin/python -m pip install some-package

# Windows (manual venv)
ComfyUI\venv\Scripts\python.exe -m pip install some-package

You do not need to activate the venv first. Pointing at its Python directly with -m pip is more precise than source venv/bin/activate followed by a bare pip install, because activation is state that can silently expire in a new terminal while the explicit path cannot.

Portable (python_embeded)

cd ComfyUI_windows_portable
python_embeded\python.exe -m pip install some-package

This is the exact pattern the official dependencies doc recommends for custom-node requirements, with the general form:

python_embeded\python.exe -m pip install -r ComfyUI\custom_nodes\YourNode\requirements.txt

Conda env

conda activate comfyenv
python -m pip install some-package

With conda, make sure the active comfyenv is the one ComfyUI was launched under. A second, forgotten conda env is just another flavor of the same two-Python trap.

Step 3: Prove the Fix (Don’t Just Restart)

After installing, verify the package is importable from ComfyUI’s own interpreter before you restart and reload the workflow. This is the step most people skip, and it’s the difference between a fix and another round of guess-and-check.

# Linux / macOS venv
/home/kings/ComfyUI/venv/bin/python -c "import some_package; print(some_package.__version__)"

# Windows portable
python_embeded\python.exe -c "import some_package; print(some_package.__version__)"

If the import prints a version without a ModuleNotFoundError, the package is now visible to ComfyUI. If it still errors, you installed into the wrong interpreter and the above command will tell you instantly—without the slower loop of restarting ComfyUI and re-running the workflow each time. Only after the import succeeds do you restart ComfyUI, then reload the node. Going forward, the maintainable habit is: on a manual install, always put a copy of that exact <venv>/bin/python -m pip install ... line in your notes next to the node name, so the next dependency has the correct target already written down.

Common Pitfalls That Make the Trap Worse

Several habits quietly convert this into a recurring problem rather than a one-time fix.

• Running sudo pip install. Besides bypassing the environment, sudo often resets PATH and HOME, so the pip that runs is the system one, not the venv’s. It also writes into system-owned directories, which is the exact contamination a venv exists to prevent.
• Trusting pip --version instead of python -m pip --version. The bare pip on your PATH may belong to yet another interpreter. The -m pip form removes the ambiguity.
• Installing into the venv after ComfyUI is already running, then rebuilding the node without a real restart. Python caches imported modules; custom nodes import at startup. A dependency installed while ComfyUI is up will not be picked up until the process restarts.
• Mixing PyTorch versions. If a custom node requires a newer torch than the venv has, running pip install torch inside the venv can silently downgrade/upgrade the very build ComfyUI depends on, breaking every other node. Prefer nodes whose requirements match ComfyUI’s own torch, and check pip show torch in the venv before and after.
• Editing the wrong requirements.txt. Each custom node ships its own requirements.txt inside custom_nodes/<Node>/. Installing ComfyUI’s top-level requirements.txt does nothing for a node’s missing third-party package.

Conclusion

The “installed but still missing” error is almost never a broken package. It’s an environment boundary: ComfyUI runs an isolated Python (a venv, conda env, or portable python_embeded), and a bare pip install lands in your system interpreter instead. The fix is a three-step loop that takes about a minute:

• Find the real interpreter with ps aux | grep main.py (or by locating python_embeded).
• Install with -m pip through that exact interpreter, never a bare pip or sudo pip.
• Prove it with a live import in ComfyUI’s own Python before restarting, so a failed fix surfaces in seconds instead of a full restart cycle.

Once you’ve internalized “install into the interpreter ComfyUI uses, not the one on my PATH,” a whole class of custom-node import errors stops being a mystery. If you’re still stuck after confirming the package imports in the correct environment, the problem moves to the node itself—and that’s a different investigation, one worth tackling separately.

For more on diagnosing broken custom nodes generally, see our walkthrough of ComfyUI “No Module Named” errors and how to diagnose broken custom nodes.