SP_Pass

Before you build anything around SP_Pass, look at where it lives in the node menu: the pack's own category tag for it is _test_. That's the author telling you, in the most direct way a node menu can, that this one's scratch space rather than a shipped feature. Worth knowing going in, because the rest of this article is going to describe what the schema says it does - not promise it's a polished tool you should reach for first.

What it does

SP_Pass takes one value of any type and hands it back out unchanged, alongside a type dropdown widget. That's the whole node: a single "any" input, a single "any" output, and a type selector sitting next to them. In practice that shape is a passthrough - wire something into it, and the same thing comes out the other side.

The type widget is where it gets murky. In the schema this pack ships, that dropdown reports zero populated choices, which usually means the option list is built dynamically at runtime from whatever value or type is currently connected, rather than from a fixed list baked into the node definition. That's consistent with what a debug/test node for a loosely-typed pipeline would need: a way to inspect or coerce what type ComfyUI thinks is flowing through a given wire, on the fly.

Why you'd reach for it (or not)

SP-Nodes leans hard on ComfyUI's wildcard "any" type - SP_SwitchBooleanAny, SP_SelectItemFromAnyList and SP_UnlistValues all pass arbitrary values around without caring what they are. That's convenient, and it's also exactly the pattern the ComfyUI community has pushed back on: a well-known thread arguing against loose "route anything to anything" nodes made the case that they save you rewiring at the cost of a graph nobody, including future-you, can debug by looking at it. SP_Pass reads like a tool the author built to poke at that problem while developing the rest of the any-typed nodes in this pack - a way to confirm what's actually flowing through a wire before trusting it downstream.

If you're just building a workflow, you probably don't need SP_Pass at all. The nodes it likely exists to support - the switch, the list selector - are the ones with actual jobs. Treat SP_Pass as a debugging aid for graphs that are already using SP-Nodes' any-typed plumbing and behaving strangely, not as a general-purpose utility you build a workflow around.

Installing it

SP_Pass ships inside the SP-Nodes pack, so you install the whole pack to get it:

• ComfyUI Manager (recommended): open Manager, search "SP-Nodes", install, restart ComfyUI.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/bananasss00/ComfyUI-SP-Nodes, then restart ComfyUI.

The README doesn't list any extra Python dependencies or model downloads for the pack's general-purpose utility nodes - SP_Pass included - so a restart after cloning should be all it takes to see it in the node menu.

Troubleshooting

There's no dedicated community discussion of this pack or this specific node to draw failure reports from, and inventing them would be worse than saying nothing. The one honest thing to flag: because the node's type widget depends on runtime state rather than a fixed choice list, don't be surprised if it behaves differently across ComfyUI versions or renders oddly in the UI - that's the nature of a _test_-tagged node, and it's a reasonable prior for any node in this category across any pack. If SP_Pass errors out or does something you can't explain, the fix is usually to route around it rather than debug it: it's not load-bearing for anything else in the pack.