Append To Text File (Soze)

This pack's other text-writer, Save Text File To Output, replaces (or refuses to replace) whatever's at the target path. This one does the opposite job on purpose: it adds to what's already there. That makes it the right node for logging - a running record of which prompt or seed produced which output, a batch job's progress, anything where each run should add a line rather than start the file over.

How it works

Give it filename_path and append_text, and it opens that file in append mode and writes the text onto the end. If the file doesn't exist yet, standard append-mode behavior applies - it gets created fresh on the first write, no separate "create the file" step needed.

There's no overwrite toggle here, unlike Save Text File To Output - appending is the entire point, so that setting doesn't apply.

The inputs and outputs that matter

Just two required inputs: filename_path (STRING) and append_text (STRING). No outputs - like the other write-only nodes in this pack, it's flagged as an output node and is a dead end in the graph.

How to install it

ComfyUI Manager → search "ComfyUI_Soze" → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/SozeInc/ComfyUI_Soze.git
pip install -r ComfyUI_Soze/requirements.txt

then restart. Plain file I/O, no external dependency.

Common issues & troubleshooting

If every run's line is running together into one unbroken blob instead of stacking one entry per line, add your own newline into append_text. A lot of lightweight append nodes like this one don't insert a line break for you automatically - build it into the string yourself (a trailing \n, or prepend one) if you want each call to land on its own line.

Same absolute-vs-relative path caveat as any raw-path file node in this pack: a relative filename_path resolves against wherever the ComfyUI process was launched from, not against your workflow file or your input/ folder. If a path you expect to work throws an error, try the full absolute path first.

Pair this with Output Filename if you want the log's own path to be predictable and organized rather than a single hardcoded string you have to remember to update.

One more thing worth planning around: a plain append-mode write like this has no built-in locking. If you're running several workflow executions concurrently against the exact same filename_path - a batch farm, several queue workers - interleaved writes to one file can, in principle, land out of order or clobber each other depending on how the OS handles concurrent appends. For a single sequential queue this never matters; for genuinely parallel execution against a shared log file, give each worker its own path (again, easy with Output Filename) and merge the logs afterward instead of fighting a race condition inside the node.