String Input 🍌

There isn't much to this one, and that's the point. It's a text box with one output socket: type text in, get a STRING out. No processing, no validation, nothing clever.

Why it exists as a separate node

ComfyUI already lets you type text directly into many nodes' own widgets, so a standalone string node only earns its place when you need the same text reused in more than one place, or when you're wiring together a pipeline where every step needs to talk in typed sockets rather than inline widgets - which is exactly the situation in cgem156's batch_condition family. BatchString's autogrow list of text entries, for instance, is built from individual string sources like this one; having a dedicated node makes each entry an explicit, connectable piece of the graph instead of buried inside a widget.

The pack's README also mentions it expects you might pair its nodes with ShowText from ComfyUI-Custom-Scripts (pythongosssss) for previewing string values mid-graph - worth installing alongside if you're going to be chaining several of these together and want to sanity-check what's flowing through at each step.

Inputs and outputs that matter

• text - a multiline text field, no default, no constraints.
• Output: STRING - exactly what you typed, unmodified.

That's the entire schema. No tooltip, no hidden behavior.

Installing it

ComfyUI Manager → search cgem156-ComfyUI🍌 → install → restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/laksjdjf/cgem156-ComfyUI

then restart ComfyUI. Nothing to download for this node - it's about as dependency-free as a custom node gets.

Common issues & troubleshooting

There isn't much that can go wrong with a text box, but a few things trip people up around it:

Wondering why you'd bother installing a whole pack for this. You probably wouldn't, on its own - if all you need is a reusable string, this is one of the smallest and safest nodes to include, but it's not a reason to install cgem156-ComfyUI by itself. It earns its keep as a building block for the other batch_condition nodes (BatchString, PrefixString, CLIPTextEncodeBatch) rather than in isolation.

Multiline text getting collapsed or mangled downstream. If a node further down your graph expects a single line, line breaks you typed here will carry through as-is - strip them yourself before that node if it matters, since this one won't do any cleanup for you.

Expecting variables or wildcards. This is plain, static text - no {a|b|c} syntax, no dynamic prompts, no substitution. If you want randomized or templated text, that's what RandomColorPrompt (for color variation specifically) or a dedicated wildcard/dynamic-prompts node is for.