ComfyUI ‘This action is not allowed with this security level configuration’: How to Fix It Safely

You open ComfyUI-Manager, click Install on a custom node, and instead of a progress bar you get a red line: This action is not allowed with this security level configuration. You then edit config.ini, set security_level = weak, restart — and nothing changes. Or you edit the wrong config.ini because there are now two possible locations. This error is one of the most commonly misdiagnosed problems in ComfyUI today, in large part because the fix has shifted across several versions and the naming has quietly changed underneath everyone.

This guide walks through what the error actually means, how to read the security-level model correctly, where your config.ini really lives, and — most importantly — how to unblock yourself without defaulting everything to weak and silently exposing your install to the exact supply-chain risks you installed this guard against. I keep the reasoning tied to the official ComfyUI-Manager documentation and issue tracker rather than memory, because the paths and values have changed more than once.

What the error actually means

ComfyUI-Manager ships with a feature-level security model. Rather than a single on/off switch, it classifies every management action into a risk level, then gates those actions behind a security level you configure. When you see This action is not allowed with this security level configuration, it does not mean ComfyUI is broken — it means the action you tried is classified at a higher risk tier than your current security_level will permit.

Per the official configuration reference, the three risk tiers map to concrete features:

• High risk — install via git URL, pip install, installing custom nodes that are not in the default channel, and the “fix custom nodes” action.
• Middle risk — uninstall/update, installing custom nodes from the default channel, restore/remove snapshot, and restart.
• Low risk — updating ComfyUI itself.

The security levels then selectively enable those tiers:

• strong — refuses both high- and middle-risk features.
• normal — refuses high-risk features; allows middle-tier features.
• normal- — same as normal, but only tightens the high-risk block when ComfyUI is launched with --listen on a non-loopback address.
• weak — allows everything.

So the most common trigger is mundane: you tried to install a node by git URL (a high-risk action) while your install is still on the default normal. ComfyUI is behaving exactly as configured. The “fix” is to understand what you actually need to permit, not to nuke the entire guard.

Diagnose before you edit: which config file, which version

The single biggest source of “I changed it and nothing happened” is editing the wrong file. The config.ini location changed with ComfyUI v0.3.76 and ComfyUI-Manager V3.38, and older installs that predate the change still carry the old path. Check both:

• ComfyUI v0.3.76+ (with the System User API): <USER_DIRECTORY>/__manager/config.ini
• Older versions: <USER_DIRECTORY>/default/ComfyUI-Manager/config.ini

Here <USER_DIRECTORY> defaults to ComfyUI/user and can be overridden with --user-directory. The reliable way to confirm which path your install uses is to read the Manager startup log — ComfyUI prints the exact config.ini path at launch. If you edited a file and saw no effect, there is a strong chance you edited a stale copy in the old location while your running install reads the new one (or vice versa).

A second, subtler failure mode shows up on older ComfyUI-Manager versions. Historically the setting was named disable_unsecure_features, and it was later migrated to security_level. Some installs carried a leftover disable_unsecure_features = False line into the new config, and because the new code ignores that legacy key entirely, users believed they had “disabled the security” when they had not. The documented resolution from the issue tracker is simply to remove the legacy disable_unsecure_features line and rely on security_level.

The safe fix: match the level to the action

Once you have located the correct config.ini, open the [default] section and set the value that corresponds to what you are trying to do. The key principle: use the minimum level that unblocks you.

[default]
security_level = normal

If you only need to install a node from the default channel, the default normal already permits it (middle-tier). You hit the error only because you used a high-risk path — git URL, pip install, or a node outside the default channel. In that specific case the documented recommendation is:

[default]
security_level = normal-

The normal- tier is the useful middle ground most people are actually looking for: it keeps the high-risk block in place only when ComfyUI is exposed over the network with --listen (the exact scenario where an attacker could drive git-URL installs remotely), while allowing the full high-risk feature set on a purely local, loopback install. This is materially safer than jumping straight to weak.

Only drop to weak if you genuinely need unrestricted git-URL and pip install access on a networked install, and understand the tradeoff. The official docs are explicit that weak means all features available, and the high-risk bucket exists specifically because those operations can run arbitrary code from the internet. If you installed a node by git URL and it pulled a malicious payload, allowing that by default is exactly how a supply-chain compromise happens. For concrete examples of what that looks like in the wild, see our write-up on malicious ComfyUI custom nodes (RATs and cryptominers) — it is the reason this guard was built in the first place.

One more modern wrinkle worth knowing: newer ComfyUI-Manager releases have begun moving away from relying on security_level = weak alone for pip-install and git-URL installs, toward explicit opt-in flags. The README notes that if you previously relied on weak (or normal-) to enable install-via-git-URL or pip install, you must now opt in with those dedicated flags. If you set the level correctly and a git-URL install still refuses, check whether your Manager version expects a separate flag rather than assuming the level is being ignored.

Why it locks down only on networked installs (and what that changes)

A point that trips people up: these blocking measures “only operate when you allow non-local network connections through the --listen option.” That means the highest-risk surface is a ComfyUI server that is reachable by other machines — cloud GPU instances (RunPod, AutoDL, vast.ai, your LAN) are the canonical cases. On a cloud box, --listen 0.0.0.0 is common precisely so you can reach the web UI remotely, and it is precisely then that the security-level gate becomes both active and important.

This reframes the fix correctly. On a cloud instance you do not want weak; you want normal- or a scoped normal at most, so a remote request cannot silently trigger a git-URL install. On a purely local, single-user desktop that never binds --listen, tightening to normal- gives you the full workflow freedom with essentially no additional attack surface. Matching the level to where ComfyUI is exposed is the difference between “I fixed the error” and “I fixed the error and left a remote-install hole.”

Verifying the fix actually took

After editing and restarting, don’t just re-click the install button — confirm the setting is being read from the location your running build actually uses:

1. Restart ComfyUI and read the startup log. Confirm the config.ini path it reports matches the file you edited.
2. Confirm the effective level. In older UI builds the Manager header or a tooltip shows the active security level; if you edited the wrong file, the level shown will not match your edit, which is your signal.
3. Retry the exact action that failed (same node, same install path). If a git-URL install still refuses under normal-, check for the newer explicit opt-in flag described above before escalating to weak.

If the error persists across a correct edit and restart, stop changing the level blindly and instead confirm your ComfyUI-Manager version against the issue you hit — the meaning of security_level, the config path, and even whether a given tier is honored have all changed across releases, and a stale Manager build can silently ignore settings that a current build respects. Updating ComfyUI and ComfyUI-Manager together is often the real fix when a value “doesn’t work.”

Key takeaways

• This action is not allowed with this security level configuration means you attempted a higher-risk action than your current level permits — usually a git-URL or pip install on the default normal level.
• Locate the correct config.ini first: __manager/config.ini on v0.3.76+, default/ComfyUI-Manager/config.ini on older builds.
• Prefer normal- over weak: it unblocks high-risk installs on local installs while keeping the guard active on --listen networked instances.
• Remove any legacy disable_unsecure_features line — it is ignored after the migration to security_level.
• These gates matter most on cloud/LAN installs where --listen exposes the web UI to other machines.

For the authoritative reference on every option — including the full config.ini key table, network modes, and the protected __manager path — see the official ComfyUI-Manager configuration documentation, and the Manager troubleshooting guide for the security-policy section. If you are fixing this on a networked setup, also review our ComfyUI API nodes sign-in guide to understand how remote access and authentication interact with what the security level is protecting.