Shima CLIP Pass

This is the most boring node in the pack, and it's boring on purpose. Shima CLIP Pass takes a CLIP model on the input and puts the exact same CLIP model on the output. Nothing else. It exists to solve a wiring problem, not a generation problem, and understanding that makes the whole "Passer" family of Shima nodes click into place.

Why a pass-through node exists at all

Two reasons, both from the pack's own docs. First: when Shima auto-connects nodes using the Use Everywhere system (broadcasting outputs to matching inputs across a workflow), a required input can get grabbed by an auto-wire with the wrong type. Passers declare their input as optional, so ComfyUI's auto-wiring won't force mismatched connections onto them - they act as stable, type-safe landing pads at the edge of an "island." Second: they're protective plugs. If a node downstream is expecting a CLIP and you don't have one handy yet, a Passer sits there as an explicit, readable placeholder instead of a confusing dangling socket.

The mechanism is one line in the source: execute(self, clip=None): return (clip,). Optional input, same thing back out. No caching tricks, no transforms, no surprises.

The inputs and outputs

• clip (optional input) - any CLIP, e.g. from a checkpoint loader or Shima's Model Citizen.
• clip (output) - the same object, passed through unchanged.

That's the whole surface. If it ever does something to your data, file a bug.

When you'd actually use it

The honest use cases:

• A stable target for Use Everywhere. In a Shima island workflow, a Passer is where broadcast CLIP signals land, so the graph has a predictable connection point instead of wires flying across the canvas.
• Organizing a wire run. Run your CLIP down a clean path - through the Passer - so it doesn't cross the whole graph diagonally before reaching the text encoder. Same job as a reroute, with a typed label.
• Protecting an optional branch. If a sub-workflow sometimes gets a CLIP and sometimes doesn't, the optional input absorbs both cases without erroring.

What it's not for: you won't need it in a simple workflow where the loader is three nodes from the encoder. Reach for it when a graph gets big enough that you're actively fighting wire spaghetti.

Installing it

Part of the Shima pack - ComfyUI Manager → search Shima, or:

cd ComfyUI/custom_nodes
git clone https://github.com/KDB-USJP/shima_wf.git Shima

Restart ComfyUI. First launch auto-installs the pack's Python deps and companion repos (ComfyUI-Impact-Pack, cg-use-everywhere). No models, no extra downloads for this node.

Common issues

There's really one trap, and it's a conceptual one: expecting the Passer to do something. It won't. If your workflow "works through" a Passer, what's actually happening is that the pass-through preserved the data while giving you a handle to wire against. The moment you find yourself wondering "did this node change my CLIP?" - no. It didn't. And that's the correct behavior.

The broader family - Image Pass, Latent Pass, Model Pass, VAE Pass, Conditioning Pass - all work identically for their own types. Learn one, you've learned the rest. If your instinct is "this is pointless," you're right, and that's precisely the point: plumbing nodes earn their keep by being the most forgettable thing in the graph.