XB-BOX - ⚡ 节点状态开关

Right-clicking a node and picking Mute or Bypass is fine when you're tweaking one branch. It's a nightmare when you're running a comparison grid and want half the graph to turn off based on a checkbox. XB_NodeStatusSwitch is XB_ToolBox's answer: a boolean in your workflow that mutes or bypasses other nodes automatically.

The mechanic is the pack's LiteGraph plumbing in action - the same "mirror clone" machinery behind its Dashboard Zen. You bind a target node to the switch by connecting any output of the target into the switch's input. When the switch's boolean flips, the frontend reaches back and changes the target node's status for you. It's programmatic mute/bypass, driven by data flow instead of context menus.

How it works

Three inputs, one output:

• enabled (BOOLEAN, default true) - the master switch.
• trigger_on - true → active or false → active. This decides whether a true value activates the switch (and applies the action) or whether a false does. Flip it when your upstream logic is inverted.
• action - mute or bypass. Mute stops the target from executing; bypass passes its inputs through untouched (skipping its work). The distinction matters: bypass keeps the graph connected, mute just makes it a hole.

The output is enabled_out, a BOOLEAN - and this is the feature that makes it more than a one-shot. You can chain switches: wire enabled_out of switch A into the enabled input of switch B, and B follows A. Build a master kill-switch that mutes a whole column of nodes at once.

The binding gotcha

Here's the part nobody tells you and the reason people bounce off this node: you bind the target by connecting its output into the switch. The switch has no visible "target selector" dropdown - the binding is the wire. If you connect nothing, the switch has no target and does nothing. Connect a node's output, and that node becomes the one being muted/bypassed.

Because the input is a wildcard, you can hang it off anything - model, latent, string, doesn't matter. The input value isn't used for anything except identification; the real work happens in the JS layer when the boolean flips.

Where it fits

• A/B testing - two prompt encoders, one active; flip the checkbox, the other branch takes over.
• Big workflow cleanup - an "all quality nodes on/off" master switch rather than right-clicking through fifteen detailer nodes.
• Chained staging - mute the VAE decode while you iterate prompts, then re-enable it for the final run.

Realistically it shines in workflows you reuse, not one-offs. Setting the binding wire up takes the same two seconds a right-click would, so if you never re-run a graph, this buys you nothing. But for a template you run ten times a day with different toggles, it's the difference between a two-click setup and a right-click scavenger hunt.

Install & notes

cd ComfyUI/custom_nodes
git clone https://github.com/WJLUOXIAO/XB_ToolBox.git
# or: ComfyUI Manager → "XB_ToolBox"

No deps, no models. Common confusion: people expect the switch's output to be the target's data. It isn't - the output is just the boolean for chaining. The target node's data keeps flowing through its own original wires; this node only touches its status, not its data.

One more trap: if you mute the node the switch is wired from, the switch itself can lose its trigger. Keep the switch wired to a node that always runs, or you'll find your master switch quietly dead.