Edit Prompt from Config

What it's for

Edit & Composite Config holds four pieces of text: the edit instruction plus three short stitch-mask prompts. All of them need to reach nodes that take a plain STRING - a text encoder, or one of three promptable segmenters. Typed bundles don't connect to primitive sockets.

This reader is the adapter, and its one widget is a selector: inpaint_prompt, stitch_prompt_1, stitch_prompt_2 or stitch_prompt_3. Pick which field you want, get it as a STRING out of the prompt output.

Why it's split into four fields

Because a real workflow needs four strings, and one blob you'd have to split by hand is worse. The old 1.x design had a single multiline stitch_mask field; 2.0 breaks it into three discrete stitch prompts so three separate segmentation inputs can each be driven by its own short phrase.

The distinction that actually matters in use: inpaint_prompt is the instruction for the editor model - a sentence describing the change, and the shape of the 2026 workflow where a masked instruction edit does the job a mask-plus-ControlNet-plus-adapter used to do. The three stitch prompts are mask prompts - short phrases naming the region the segmenter should isolate for the stitch-back. If you put a paragraph in stitch_prompt_1, you'll get scrappy masks and wonder why.

Wiring it

One input (edit_config), one output (prompt). Nothing else, no state, no rerun of anything - readers expose existing values rather than recomputing.

Edit & Composite Config ─┬─> (reader) [inpaint_prompt]   ─> editor text encode
                         ├─> (reader) [stitch_prompt_1] ─> segmenter A
                         ├─> (reader) [stitch_prompt_2] ─> segmenter B
                         └─> (reader) [stitch_prompt_3] ─> segmenter C

Three readers instead of one, deliberately. Each sits beside the node it feeds, so a glance at the canvas tells you which prompt is driving which mask. One reader fanned out to three segmenters would send the same string to all three, which defeats the point of having three fields.

Where people get burned

If your saved workflow has an Edit Prompt from Config node selecting stitch_mask, that selection is retired and needs changing to stitch_prompt_1, _2 or _3. This is a breaking release by design - the pack's release notes say so plainly, and it's why old PortraitUtilsv5.2.json-era workflows show missing or invalid nodes rather than quietly working.

Second: don't try to wire edit_config into a PrimitiveString. The bundle's type is PORTRAIT_EDIT_CONFIG_V2; only readers and matching PortraitUtils consumers accept it. Same reason you can't "Convert widget to input" your way around it.

Third, an easy one to miss: whichever field the selector points at is what you get, and the widget is the only clue. If a segmenter is masking the wrong thing, check the selector before you go rewriting prompts.

Related readers

Same one-in-one-out shape across the suite, if you're wiring a few of these in one session:

• Crop Prompt from Config - subject_mask as a STRING.
• Outpaint Prompt from Config - the outpainting prompt.
• Seed from Config - the run seed as an INT.
• Scale from Config - initial_upscale or final_upscale as a FLOAT.
• Save Info from Source - filename and output directory from the loader's source bundle.

Install

Part of PortraitUtils. ComfyUI Manager → search PortraitUtils (publisher heyburns, GPLv3), or:

cd ComfyUI/custom_nodes
git clone https://github.com/heyburns/PortraitUtils
/path/to/ComfyUI/venv/bin/python -m pip install -r PortraitUtils/requirements.txt

Install into ComfyUI's Python environment, not a system interpreter: numpy, Pillow>=9.1, opencv-python-headless>=4.10.0.84 and tifffile, with only one OpenCV wheel variant present. Restart the ComfyUI server afterwards - a browser refresh alone won't register new node classes, which is the usual cause of "I installed it but can't find the node."