ComfyUI Manager Install Failed: Registry and Path Fixes

Most ComfyUI Manager installs that fail the instant you click are not network failures. They are refused locally, because Manager decides what you may install from the address the server is bound to: is_local_mode = is_loopback(args.listen). 0.0.0.0 is not a loopback address, so ComfyUI Desktop and any LAN-exposed server fall out of local mode and lose git-URL and pip installs entirely. Bind to 127.0.0.1, or set security_level = weak in Manager's config.ini, and the identical click succeeds. If you are instead staring at a ModuleNotFoundError, that is a different family: Manager installs into whichever interpreter is running ComfyUI — sys.executable — and on portable and Desktop builds that is not the Python on your PATH.

The reason this is miserable to search is that three unrelated failures wear the same coat. A permission refusal, a wrong-interpreter dependency install and a stale registry cache all surface in the Manager panel as an install that did not work, and two of the three write nothing useful into the dialog. The fix for each is one line, but you have to know which one you have.

Everything quoted below was read out of the ComfyUI-Manager source on main and ComfyUI's own comfy/cli_args.py on master in August 2026, at ComfyUI-Manager 3.41 (the version string in the repository's pyproject.toml). Issue numbers are linked so you can check whether yours has been fixed since.

Which Failure Are You Actually Looking At?

Find your row first. The fixes are genuinely unrelated, and applying the wrong one wastes an evening.

That last row is a different article's problem entirely — a node that installed cleanly and then fails to import is covered in ComfyUI missing node types.

Why Does the Install Fail Instantly With No Error?

Because Manager rejects the request server-side with a 403 before anything is downloaded, and the front end has nowhere to put the reason. Two issues filed on the same day in May 2026 describe the two halves of this perfectly.

Issue #2853 is the symptom: "[Bug] Extension install fails instantly (0ms) with no error_message on ComfyUI Desktop macOS — operation returns failed but nothing happens" (opened 5 May 2026, still open). Issue #2854, filed by the same reporter the same day, is the diagnosis: "[Bug] Desktop listen address 0.0.0.0 causes is_local_mode=False, blocking all installations". The environment there was ComfyUI Desktop 0.8.36 on macOS; the batch history JSON came back with a failed result and a null error message, and the underlying HTTP response was a 403.

The reason nothing appears in the UI is visible in the server code. Manager's refusal path returns a bare JSON body:

security_403_response()   # -> {"error": "security_level"}, status 403

and writes the human-readable part to the terminal instead. The strings you are looking for in your console are these, verbatim from glob/manager_server.py:

ERROR: This installation is not allowed in this security_level.
ERROR: To use this action, security_level must be any value other than 'strong'
A security error has occurred. Please check the terminal logs

So the first thing to do is stop looking at the browser and look at the ComfyUI console. If one of those lines is there, you have a permission problem and the next section is your fix. If the console is clean, skip ahead — you have a Python path or registry problem instead.

One aggravating factor worth knowing about: issue #3128, "Batch install/uninstall map every 404 to the 'default channel' message, masking the real denial reason" (closed 15 August 2026), describes exactly the class of bug that makes this hard — a real refusal reason getting flattened into a generic message on its way to the UI.

How Does Manager Decide That You Are Local?

It calls one function on the string you passed to --listen, and that function is stricter than almost anyone expects. From glob/manager_server.py:

def is_loopback(address):
    import ipaddress
    try:
        return ipaddress.ip_address(address).is_loopback
    except ValueError:
        return False

is_local_mode = is_loopback(args.listen)

ipaddress.ip_address() parses a single IP literal and nothing else. Anything it cannot parse raises ValueError, which this function turns into False. That produces results people do not predict:

The bare-flag row is the trap. ComfyUI's own argument definition in comfy/cli_args.py reads default="127.0.0.1" with nargs="?" and const="0.0.0.0,::", and its help text spells it out: "If --listen is provided without an argument, it defaults to 0.0.0.0,:: (listens on all ipv4 and ipv6)". So adding a bare --listen to reach ComfyUI from your phone also, invisibly, revokes Manager's git-URL and pip install permissions. The localhost row is the second trap, and it is the crueller one, because --listen localhost looks maximally safe and still fails the check.

Two gates read that flag. The first is the dedicated-install predicate:

def is_dedicated_install_allowed(flag_value: bool, listen_address: str) -> bool:
    return bool(flag_value) and is_loopback(listen_address)

It guards POST /customnode/install/git_url and POST /customnode/install/pip, using allow_git_url_install and allow_pip_install from config.ini respectively. Both default to false, and both are ANDed with loopback — so setting the config flag alone changes nothing while you are bound to 0.0.0.0. That is precisely the complaint in issue #3023, "'allow_git_url_install = true' Doesn't work" (opened 27 June 2026, open), and the feature request in issue #3053, from someone running ComfyUI on a second machine inside a firewalled network and asking for the behaviour back.

The second gate is the security-level check, and this is where normal- earns its odd name:

def is_allowed_security_level(level):
    if level == 'block':
        return False
    elif level == 'high':
        if is_local_mode:
            return core.get_config()['security_level'] in ['weak', 'normal-']
        else:
            return core.get_config()['security_level'] == 'weak'
    elif level == 'middle':
        return core.get_config()['security_level'] in ['weak', 'normal', 'normal-']
    else:
        return True

Read the high branch carefully. normal- is exactly normal plus "trust high-risk actions, but only while I am bound to loopback." Move the bind to 0.0.0.0 and normal- silently collapses back to normal. Nothing in the UI tells you this happened.

What Do the Security Levels Actually Permit?

Set the level in Manager's config.ini and restart ComfyUI — the value is read at startup, not per request. Do not guess where that file lives: Manager prints its own path at startup, as ** ComfyUI-Manager config path:, alongside ** ComfyUI Path: and ** User directory:. Scroll to the top of your console and read it.

Those first two columns come straight from the call sites: the handlers for /manager/queue/install, /manager/queue/update, /manager/queue/update_all, /manager/queue/uninstall, /manager/queue/fix, /manager/queue/install_model and /manager/reboot all test is_allowed_security_level('middle') and return a 403 when it fails. The model-download handler adds a second, stricter test:

if not json_data['filename'].endswith('.safetensors') \
        and not is_allowed_security_level('high'):

That is a sensible rule and worth leaving alone: a .ckpt is a pickle and can execute code on load, a .safetensors file cannot. If a model download is the only thing failing for you, downloading the .safetensors build is a better answer than lowering your security level.

The pragmatic recipe, in order of how little you give up:

1. If ComfyUI runs on the same machine you browse from, launch it with --listen 127.0.0.1 (or drop --listen entirely) and restart. Everything works and nothing is exposed.
2. If you need LAN access, keep the loopback bind and reach it through an SSH tunnel or a reverse proxy, so the server itself still sees a loopback address.
3. Only if neither is possible, set security_level = weak in config.ini — and understand that you are re-enabling arbitrary-code installs on a server that is reachable from your network. Issue #2854 lists both of these as its workarounds.

Which Python Does ComfyUI Manager Install Into?

Whichever one is running ComfyUI. There is no venv discovery, no search, no heuristic. The whole resolution lives in glob/manager_util.py:

@lru_cache(maxsize=2)
def get_pip_cmd(force_uv=False):
    embedded = 'python_embeded' in sys.executable
    if not force_uv:
        try:
            test_cmd = [sys.executable] + (['-s'] if embedded else []) + ['-m', 'pip', '--version']
            subprocess.check_output(test_cmd, stderr=subprocess.DEVNULL, timeout=5)
            return [sys.executable] + (['-s'] if embedded else []) + ['-m', 'pip']
        except Exception:
            logging.warning("[ComfyUI-Manager] `python -m pip` not available. Falling back to `uv`.")

Three things follow from those six lines, and all three explain real reports:

• The "portable" detection is a substring test. embedded = 'python_embeded' in sys.executable — that is the entire check. If it matches, Manager adds -s, which tells Python to ignore the user site-packages directory, so a portable build cannot accidentally pick up packages from a system-wide install. Rename or relocate your portable folder such that the path no longer contains python_embeded and you quietly lose that isolation.
• If python -m pip does not answer within 5 seconds, Manager switches to uv. It tries uv as a module first, then as a standalone executable, and logs the warning quoted above when it does. uv is a declared dependency of Manager, so this path is normal, not broken — but it means your dependencies can be installed by a resolver different from the one you tested with. use_uv in config.ini forces it either way.
• You can see the exact interpreter without guessing. Manager's prestartup script prints ** Python executable: followed by sys.executable every time ComfyUI starts. That line is the ground truth for every manual command in the next section.

For Desktop specifically, the ComfyUI docs give the install roots — %LOCALAPPDATA%\Comfy-Desktop\ComfyUI-Installs on Windows and ~/ComfyUI-Installs on macOS, with logs at %APPDATA%\Comfy Desktop\logs and ~/Library/Logs/Comfy Desktop respectively. The docs do not publish the interpreter path inside those directories, which is exactly why the startup line matters more than any article's guess.

Why Does It Say ModuleNotFoundError: No Module Named comfy?

Because comfy is ComfyUI's own package directory, not something on PyPI, so it only imports when the process is rooted in your ComfyUI folder. A custom node's install.py, a build step in its requirements.txt, or a helper script launched with a different working directory or a different interpreter will not find it, and pip reports the resulting traceback as a failed install. Issue #2556 carries the message as its title — "[ComfyUI-Manager] Installation failed: ModuleNotFoundError: No module named 'comfy'" — and has been open since 29 January 2026.

Do not try to pip install comfy. That is a different, unrelated package.

The sibling failures are worth telling apart:

• No module named 'comfy_aimdo.vram_buffer' (#2852, closed 21 May 2026) and No module named 'comfy_aimdo' on a fresh Colab install (#2579, open since 4 February 2026) point at ComfyUI itself, not at Manager. comfy_aimdo is the package behind ComfyUI's DynamicVRAM memory manager — comfy/model_management.py imports comfy_aimdo.host_buffer and comfy_aimdo.vram_buffer directly. A missing or version-mismatched wheel there breaks startup regardless of what Manager does. The fix is to reinstall ComfyUI's own requirements.txt with the interpreter from your ** Python executable: line.
• #3064 (open, 8 July 2026) is narrower and easy to miss: a bare import manager_core on the aria2 download path raises ModuleNotFoundError when Manager is used as a pip package, so every model install fails while COMFYUI_MANAGER_ARIA2_SERVER is set. If you set that variable once and forgot, unset it and retest.

What Do the ComfyRegistry Errors Mean?

Manager talks to one host — https://api.comfy.org — with a 30-second timeout, and caches what it gets for 24 hours. The three strings you will see in the console, verbatim from glob/cnr_utils.py, map to three different situations:

The endpoints in play are /nodes, /nodes/{node_id}/install and /nodes/{node_id}/versions, and the cache lives at ComfyUI-Manager/.cache with a 24-hour freshness window (86400 seconds in manager_util.py). A partially written cache is the single most common cause of a node list that is empty, stale or stuck on "Loading" — deleting that .cache directory and restarting ComfyUI is a safe, cheap first move.

This family has a long tail. Issue #2423 is titled, with visible exasperation, "'Cannot connect to comfyregistry' - this is still throwing errors (despite being referred to as a closed issue.)" and has been open since 24 December 2025. #2933, "Failed to find the following ComfyRegistry list", was closed on 31 May 2026. #2407, "[Bug] New Manager (v4.0.3b5 -> v4.0.4) can't find custom nodes", was closed in January 2026, and #3117, "Comfyui Manager Custom nodes and Custom models list doesnt appear", was opened on 31 July 2026 and is open.

Three settings in config.ini matter here. network_mode takes public, private or offline — if someone set it to offline to work on a plane, registry lookups will never succeed until it goes back. bypass_ssl exists for corporate TLS interception, and is the right knob for a proxy that rewrites certificates. git_exe matters when git is installed somewhere Manager cannot find it, which turns clone-based installs into failures that look like network errors.

How Do You Install a Node by Hand When Manager Will Not?

Cloning into custom_nodes yourself bypasses every permission gate above, and it is the fastest way to prove whether Manager is the problem. Manager is doing the same three steps; you are just doing them with an interpreter you can see.

Step one, find your two paths from the ComfyUI console at startup:

** Python executable: <this is the interpreter you must use>
** ComfyUI Path:      <custom_nodes lives directly inside this>

Step two, clone the node:

cd "<ComfyUI Path>/custom_nodes"
git clone https://github.com/<owner>/<node-repo>

Step three, install that node's requirements with the interpreter from the first line, not with whatever pip your shell resolves. This is where most manual attempts go wrong, and it is why the command differs per install type:

# Windows portable — run from the ComfyUI_windows_portable folder
.\python_embeded\python.exe -s -m pip install -r ComfyUI\custom_nodes\<node-repo>\requirements.txt

# Manual install or comfy-cli, with the venv activated
python -m pip install -r custom_nodes/<node-repo>/requirements.txt

# Any install, without activating anything — safest form
"<Python executable from the startup line>" -m pip install -r "<path to requirements.txt>"

Note the -s in the portable command. That is not decoration: it is the same flag Manager adds when python_embeded appears in sys.executable, and it stops the portable build from importing packages out of your system-wide site-packages. Leave it in and your manual install matches what Manager would have done.

Step four, restart ComfyUI completely — not a browser refresh — and read the console. If the node still does not appear, the install worked and the node is failing to import, which is a different diagnosis with its own error text. Our ComfyUI complete guide covers the custom-node layout, and if the failure only shows up once a workflow runs, LoRA nodes silently doing nothing and device mismatch errors are the two most common next stops. On Apple Silicon, a node that installs but then throws at runtime is usually the Metal backend rather than the node — see our notes on ComfyUI MPS errors on Mac.

One more thing worth doing while you are in there: issue #2761, "Blocked by policy: /home/comfy/ComfyUI/custom_nodes/ComfyUI-Manager", is a reminder that on locked-down or containerised hosts the block can be filesystem policy rather than Manager at all. If your manual git clone also fails, stop debugging Manager.

What Is Still Unverified Here?

• We did not reproduce these failures on our own machines. Every code block above is quoted from the ComfyUI-Manager and ComfyUI repositories, and every symptom is attributed to a numbered issue. Where we could not read a value from source — the exact interpreter path inside a Desktop install, for one — we tell you to read it off your own console instead of guessing it for you.
• Manager moves fast and the security logic has already been rewritten once. Issue #2854 describes the check as it existed in legacy/manager_server.py, where a plain install was gated on is_local_mode. On main today the gate is narrower: ordinary installs need only a middle security level, while git-URL installs, pip installs and non-.safetensors downloads are the loopback-gated ones. Your build may sit on either side of that change, which is why the console strings, not our table, are the authority.
• We have not audited the front end. Whether a given Manager UI version surfaces the 403 reason or swallows it is a moving target, and #3128 shows it has been swallowed before. Assume the terminal is more honest than the dialog.
• Nothing here is a security recommendation. security_level = weak on a machine reachable from your network means anyone who can reach port 8188 can install code on it. We describe what the flag does; deciding whether to set it is yours.

FAQ

Why does ComfyUI Manager install fail instantly with no error message?

Because the refusal happens server-side before any download starts. Manager returns HTTP 403 with a JSON body of {"error": "security_level"} and writes the readable explanation to the ComfyUI terminal, not to the browser. Issue #2853 records the exact symptom on ComfyUI Desktop for macOS: a batch history entry with a failed result and a null error message. Check the console for a line beginning ERROR: This installation is not allowed.

Does ComfyUI Manager really block installs when I use --listen 0.0.0.0?

For git-URL installs, pip installs and non-.safetensors model downloads, yes. is_local_mode = is_loopback(args.listen), and 0.0.0.0 is not a loopback address, so those three paths are refused. Ordinary registry installs on current main only require a middle security level and are not affected. Issue #2854 tracks the Desktop case and is still open.

I set allow_git_url_install = true and nothing changed. Why?

Because the predicate is bool(flag_value) and is_loopback(listen_address) — the flag is ANDed with the loopback test, so it does nothing while you are bound to 0.0.0.0. You also have to restart ComfyUI for a config.ini change to be read. That combination is what issue #3023 describes.

Which Python does ComfyUI Manager install packages into?

sys.executable — the interpreter currently running ComfyUI. There is no venv detection beyond a substring test for python_embeded in that path, which only decides whether -s is added. If python -m pip does not respond within five seconds, Manager falls back to uv. Read your own value off the ** Python executable: line that Manager prints at startup.

How do I fix "Cannot connect to comfyregistry"?

Confirm the machine can reach https://api.comfy.org, then check network_mode in config.ini — offline will never resolve the registry. If the connection is fine but the node list is empty or stale, delete the .cache directory inside ComfyUI-Manager and restart, since entries are held for 24 hours. Behind a TLS-intercepting corporate proxy, bypass_ssl is the relevant setting.

Is installing a custom node manually as good as using Manager?

For getting unblocked, yes — Manager performs the same clone plus requirements install, so doing it yourself produces the same result and shows you every error. What you lose is Manager's tracking: version pinning, the update and uninstall buttons, and the registry's security scanning. Clone by hand to break a deadlock, then let Manager take over once the underlying permission or path problem is fixed.

Sources

• Comfy-Org/ComfyUI-Manager — glob/manager_server.py (is_loopback, is_local_mode, is_allowed_security_level, is_dedicated_install_allowed, security error strings), glob/manager_util.py (get_pip_cmd, cache directory, 86400s freshness), glob/cnr_utils.py (api.comfy.org, endpoints, 30s timeout, registry error strings), glob/manager_core.py (network_mode, security_level, get_default_custom_nodes_path), prestartup_script.py (the ** startup lines), pyproject.toml (version 3.41). Read August 2026.
• ComfyUI — comfy/cli_args.py — the --listen definition, its 127.0.0.1 default and 0.0.0.0,:: bare-flag constant.
• ComfyUI-Manager issues #2407, #2423, #2556, #2579, #2761, #2852, #2853, #2854, #2933, #3023, #3053, #3064, #3117, #3128 — titles, dates and open/closed states as listed in the tracker in August 2026.
• ComfyUI Desktop file locations (Windows) and (macOS) — install, shared and log directories.