CMK Trigger Words Filter

Let's get the honest bit out of the way first: this node is a compatibility shim. Its own docstring says so - "Compatibility-preserving CMK replacement for the former toggle widget." Two of its three visible inputs are accepted and immediately discarded. If you're deciding whether to install CMK Flow for this node, don't; if you're debugging a graph and wondering why toggling group_mode changes nothing, this page is why.

What it actually does is small and useful: it sits between something that produces LoRA trigger words and something that consumes them, and it gives you a single boolean that decides whether those words are included this run.

How it works

def filter(self, group_mode=True, default_active=True, allow_strength_adjustment=False, trigger_words=""):
    del group_mode, allow_strength_adjustment
    return (str(trigger_words or "").strip() if bool(default_active) else "",)

trigger_words comes through stripped. default_active=False empties it. group_mode and allow_strength_adjustment are deleted - they exist because older CMK subgraphs wired a multi-switch widget here and the replacement node had to keep the same socket and widget shape so those graphs still load. Behaviourally they are decoration.

That matters for how you use it. In practice this is a mute for a trigger string. Leave it on and your LoRA's trigger words travel through; switch it off and the encoder receives an empty string while the rest of the prompt carries on untouched. Why would you want that? Because the alternative - bypassing the node upstream - can also mute the LoRA load itself or change the conditioning build, and sometimes you want to drop the trigger words without changing anything else. It's a scalpel, not a bypass.

It's categorised CMK/Internal, which is CMK's way of saying "you're allowed to see it, you're not really the audience." In the intended design, a LoRA stack builder produces the words and this node gates them; the pack's LoRA text convention is inline <lora:name:strength> tags parsed by a matching loader, so trigger words and LoRA application stay separate concerns.

Inputs and outputs

• trigger_words (STRING, optional, forceInput) - the trigger string. Optional and wire-only: nothing is typed here, and if nothing is connected the node returns an empty string regardless of the toggle. That's the trap worth naming: a disconnected filter looks identical to a muted one.
• default_active (BOOLEAN, default on) - the only switch that does anything. On = pass through, off = emit "".
• group_mode, allow_strength_adjustment (BOOLEANs) - accepted, ignored.

One output: filtered_trigger_words (STRING). Wire it into the prompt assembly, a CLIP text encode, or a CMK String Dual-style node if you're combining it with other text.

Install

Manager → search CMK Flow → install → restart. Manual:

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

Async note specific to a pack this new: CMK Flow was only open-sourced in July 2026 and the community footprint is small - a handful of threads, double-digit upvotes on the launch post - so an unexpected behaviour is more likely to be an un-documented design choice than a known issue with a forum answer. The source is the ground truth, and for this node it's eleven lines.

Common issues

• "I turned off group_mode and nothing happened." Correct, by design. See above.
• Empty output even though the toggle is on. Either trigger_words isn't connected, or it arrived blank. Check for the wire first.
• Trigger words appear twice in the prompt. You're likely passing the same string both through this node and straight to the encoder. Pick one path.
• Something expected a switch list. Legacy CMK subgraphs wired a switch-widget here; if you have a hand-edited or third-party subgraph from CMK 1.x expecting the old node, that's the specific thing group_mode is squatting on the socket to preserve.