CMK Process Enable Flag

A CMK_PROCESS_SDXL goes in, one BOOLEAN comes out. In between, the node reads one named key off the process dictionary and tells you whether it's true.

That sounds like it doesn't earn a whole node, and mostly it doesn't - until you try to build something that needs to react to a switch that lives inside the pack's process state. CMK's process bundle carries a pile of module flags: which family is active, whether the InstantID stage is on, whether the ControlNet branch is live, whether the face rebuild stage is running. They're all in there as booleans, and they're all invisible on the canvas, because that's the bargain you make with bundle-style wiring. This node is how one of them becomes a visible, wireable socket.

The one input that isn't a pipe

flag is a plain string widget, default instantid_enabled. You type the key name and it looks it up. Change it to another key the pack stores and you get that switch instead.

That's the entire mechanism: PROCESS.get(flag, False), wrapped in a type check that raises TypeError if PROCESS isn't a dictionary.

Which brings the trap, and it's a good one. An unknown key returns False silently. Type instantid_enable instead of instantid_enabled and you don't get an error - you get a confident False, wired into whatever you were gating, which then never fires. If your conditional stage refuses to run, suspect the spelling before you suspect the logic. There's no list to pick from and no autocomplete; the key names are a convention between you and the pack, not a validated enum.

When it is set up right, the use is genuinely tidy. You want the InstantID stage's state to control a branch elsewhere in your graph - an added face crop, a different prompt path, an extra upscale. Instead of duplicating the checkbox in two places and keeping them in sync by hand, you read the flag the pack already maintains. One source of truth, zero manual bookkeeping. That's the same argument as core's value nodes, applied to pack-internal state.

Housekeeping details

DEV_ONLY is set on the node class in the source, which is the pack's marker for developer-facing infrastructure. It's in the CMK/Developer/Pipe/Forward category and it will not appear in the Flow Browser, whose catalogue is restricted to the guided CMK/Flow/ modules. Find it by searching CMK Process Enable in the node menu.

It also doesn't run any processing and doesn't mutate the process bundle. Read-only, one lookup, no caching concerns. Cheap enough to sprinkle anywhere you need a signal.

Installing the pack

ComfyUI Manager → search CMK Flow → install the entry from CMKFlow → restart. The registry package name is cmk-flow; the folder it lands in is irrelevant to the pack.

From the ComfyUI root directory:

git clone https://github.com/CMKFlow/cmk_nodes.git custom_nodes/cmk_nodes
python3 custom_nodes/cmk_nodes/scripts/install_cmk_requirements.py

Expect CMK dependency check: OK. The installer exists because pip'ing into the wrong Python is the standard CMK failure on Desktop installs, where a system interpreter, standalone-env and ComfyUI/.venv can all be sitting there. It installs requirements.txt into whichever interpreter ComfyUI actually uses and then verifies the imports. Because the pack loads all its nodes together, a dependency that fails to build can remove nodes across the pack rather than just the ones that needed it - so treat that check line as load-bearing.

Updates:

git -C custom_nodes/cmk_nodes pull --ff-only
python3 custom_nodes/cmk_nodes/scripts/install_cmk_requirements.py

No model weights are in the Python package. scripts/check_cmk_resources.py audits your model folders against what the bundled workflows expect and can fetch missing files, including Civitai-gated ones with an API key you supply at the prompt (held in memory for that run only).

Enable Vue Nodes / Nodes 2.0 in ComfyUI settings - the pack requires it, and without it dynamic CMK nodes degrade to legacy rendering. If you want live previews during sampler and refiner runs, set Execution → Live preview method to auto.

Do you need it

If you're running CMK's published flows unmodified, no - the pack's own modules already read their flags internally. Reach for this when you're extending a graph and want the CMK state to drive something that isn't a CMK node. And when you do, verify the key name once by wiring the output into something visible before you build three branches on top of it.