CMK Process Forward -Pipe-

A node that takes a CMK_PROCESS_SDXL and gives you back the same CMK_PROCESS_SDXL. Nothing is computed, nothing is validated beyond "is this actually a dict", and if you pass None you get None back. It is, functionally, a wire with a checkbox in it.

So why does the source bother to document it as a "read-only PROCESS throughpass for CMK frontend subgraphs"? Because it's the answer to a real ComfyUI subgraph problem: to expose an incoming value at a subgraph's output, something has to be a node. If your module's process state passes through unchanged but you need that state on an output socket, you need a node, and reaching for a real processing node to do it would drag its work into the module. This one carries the pipe and does nothing else - so a subgraph can hand PROCESS out the other side without pretending to process it.

It shows up eighteen times across the pack's subgraphs and showcase workflows, which tells you how load-bearing that small job is. CMK's process bundle (CMK_PROCESS_SDXL) is what carries the generation state - which family is active, whether the branch is live, which model to load when. Modular graphs that emit process state to a neighbouring module need it at the boundary, every time, occasionally several times in one graph.

The type check is not decorative

If PROCESS isn't a dict, it raises a TypeError naming the node and the actual type it got. That's the pack's whole philosophy in one line: fail loudly at the boundary rather than pass a wrong-shaped object deeper and let the failure surface as a mysterious error three modules later. If you see that message, you wired something that isn't a CMK process pipe into the socket - the socket type should have prevented it, so check whether a graph was hand-edited or migrated from an older CMK version.

When you'd actually place one

Almost never by hand, unless you're building or editing a CMK module - a subgraph of your own that needs to forward the process state, or a workflow where you've pulled a module's guts onto the canvas and now need the state to keep flowing. Copied modules keep it internal and you never see it.

It's also a debugging tool in a small way. Wire a peek-style node off it and you can inspect what the process state actually says at a given point in the chain - useful when a branch is silently inactive and you don't know which module decided that.

Installing the pack

ComfyUI Manager → search CMK Flow → install the entry published by CMKFlow → restart. The registry package name is cmk-flow.

From the ComfyUI root:

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

Success is the line CMK dependency check: OK. A git clone never runs pip on its own, so that second command isn't a formality - the pack imports ultralytics, onnxruntime, insightface, segment-anything, opencv-python, imageio-ffmpeg and a pinned nudenet at load time, and if the import graph falls over you lose nodes across the pack, not just the ones that needed the missing library. The installer's job is to determine which Python your ComfyUI is actually running - system Python, standalone-env and ComfyUI/.venv can all be present - and install into that one.

Updates take the same two steps (git pull --ff-only, then the installer). Model weights are separate from the Python package by design; scripts/check_cmk_resources.py will audit your model folders against the bundled workflows and optionally fetch what's missing.

Before you file anything as a bug: enable Vue Nodes / Nodes 2.0 in ComfyUI settings. The pack requires it, and without it dynamic CMK nodes drop back to legacy rendering, which looks like a broken pack and isn't.

Two more paper cuts worth avoiding. Don't copy the JSON files from the pack's subgraphs/ folder into user/default/subgraphs/ - ComfyUI treats node-pack blueprints and user blueprints as different sources, and you'll get duplicate entries. And don't leave an old CMK install sitting next to a current one; the author's install notes are explicit that stale single files beside a fresh install cause trouble.

Honest summary

There is no configuration here and nothing to tune. It's one of those nodes whose value is entirely in what it doesn't do: it lets a module export its process state without running a processing stage. Search for CMK Process Forward if you're editing a module and need it; ignore it otherwise.