ComfyUI-to-Python-Extension: turn a node graph into a runnable script

The gap between a saved workflow and code you can ship

A ComfyUI workflow is a JSON graph. It runs inside the ComfyUI process, driven by the UI or the queue. The moment you want that same graph inside a test, a batch job, or a repository that other people read, you either re-enter it by hand or you keep the JSON and hope the surrounding tooling stays stable.

ComfyUI-to-Python-Extension targets that middle step. The README frames it as turning visual workflows into executable scripts so you can move from node graphs to automation, experiments, and repeatable generation. The intended user is someone who already builds graphs in ComfyUI and wants a Python file that mirrors the graph, not someone who wants to design graphs in code from the start.

That distinction matters for evaluation. This is a one-way export plus a runtime shim, not a Python SDK for ComfyUI. If your team never opens the ComfyUI canvas, the project has little to offer you.

Two entry points: Save As Script and the CLI exporter

There are two supported paths, and they produce different artifacts.

The Web UI path registers the repository as a ComfyUI custom node, which adds File -> Save As Script. The command downloads a generated .py file. Per the README, the current UI export uses the default filename workflow_api.py so it works in ComfyUI Desktop without relying on prompt(), and the menu placement can differ between frontend versions.

The CLI path takes a workflow saved in API format (File -> Export (API)) and writes a Python file. Both paths run the same conversion logic; the difference is where the frontend workflow metadata ends up. Scripts exported from the UI already include that metadata, which is why images saved by those scripts can be dropped back into ComfyUI and reopen with the original workflow metadata. The README does not claim the same for CLI output.

The generated file is not self-contained. It bootstraps ComfyUI's runtime and reuses ComfyUI's argument parser, which is why memory flags such as --highvram, --normalvram, --lowvram, --novram, --cpu, and --disable-smart-memory can be passed straight to the exported .py file.

Installing it next to ComfyUI and exporting a first script

The install has one trap that the troubleshooting section calls out twice: installing into the wrong interpreter. The extension's dependencies are declared in pyproject.toml, but they must land in the Python environment that launches ComfyUI.

For the Web UI path, clone into custom_nodes so ComfyUI can discover the repo:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/pydn/ComfyUI-to-Python-Extension.git

If you keep the repo elsewhere, the README offers a symlink or adding the parent directory to ComfyUI's custom_nodes search paths via extra_model_paths.yaml. Then install into ComfyUI's runtime Python. For a source checkout driven by uv:

cd /path/to/ComfyUI
uv pip install -e ./custom_nodes/ComfyUI-to-Python-Extension
uv run python main.py

On the Windows portable build the equivalent is the bundled interpreter, run from the extension directory:

cd C:\path\to\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-to-Python-Extension
..\..\..\python_embeded\python.exe -m pip install -e .

Restart ComfyUI afterwards. The README warns that uv sync inside the extension creates the extension's own .venv, and ComfyUI does not import dependencies from that .venv.

For CLI-only use the repo can live anywhere:

git clone https://github.com/pydn/ComfyUI-to-Python-Extension.git
cd ComfyUI-to-Python-Extension
uv sync
export COMFYUI_PATH=/path/to/ComfyUI

Then export a workflow you saved with File -> Export (API). The defaults are workflow_api.json in and workflow_api.py out, and --queue_size sets the default execution count in the generated script:

uv run python -m comfyui_to_python \
  --input_file workflow_api.json \
  --output_file workflow_api.py \
  --queue_size 10

The legacy wrapper uv run python comfyui_to_python.py still works. When it finishes you should have a .py file that runs under the same interpreter that launches ComfyUI. If it raises ModuleNotFoundError: No module named 'torch', the README's answer is that the environment you are using lacks ComfyUI's runtime dependencies, not that the exporter is broken.

What the generated script is not

The lifecycle notes are the most useful part of the README because they set expectations the marketing line does not. Exported scripts are single-shot workflow runners, not long-lived ComfyUI prompt servers, and they do not implement Web UI prompt/result caching across repeated service calls.

So if you were hoping to drop the export behind an HTTP endpoint and get ComfyUI's caching behaviour, you will be reimplementing that yourself. The generated script also does not automatically turn workflow inputs into command-line arguments; changing a prompt or a seed means editing the Python file or wrapping it. That is a deliberate scope boundary, but it is the boundary most likely to surprise someone who reads only the first paragraph of the README.

Memory handling is more thought through. The exported main() performs best-effort ComfyUI model and cache cleanup in a finally block, and you can set COMFYUI_TOPYTHON_UNLOAD_MODELS=1 or call main(unload_models=True) when an embedded or repeated-call host should aggressively unload models after each run instead of preserving them for reuse. That option only makes sense if you are calling the generated script repeatedly from another process; for a single run it is overhead.

Where COMFYUI_PATH resolution goes wrong

COMFYUI_PATH is checked first, and if it is not set the exporter falls back to searching parent directories for a folder named ComfyUI. That fallback is convenient when the repo sits inside the ComfyUI tree and confusing when it does not: a stale or wrong value produces import failures that look like missing dependencies.

The README is explicit that COMFYUI_PATH helps the exporter and generated scripts find the ComfyUI codebase, but does not by itself register the repo as a ComfyUI extension for the Web UI. It also does not install ComfyUI runtime dependencies such as torch into the current environment. Those are three separate concerns and the variable only addresses one.

The practical failure mode is a machine with two Python environments: one where you ran uv sync and one that launches ComfyUI. Everything imports cleanly in the first and fails in the second. The README's own troubleshooting list treats this as the top cause of both the Web UI import failure and the Windows portable import failure, and the fix is always to install into the interpreter that launches ComfyUI.

How it compares with the ComfyUI Python API directly

ComfyUI already exposes a Python API, and the related searches around ComfyUI Python API and ComfyUI Python node point at it. The difference is direction of authorship. With the Python API you write the graph in Python and ComfyUI executes it; with this extension you author in the canvas and ComfyUI's graph is translated into Python for you.

That makes the extension the better fit when the graph is the source of truth and non-programmers or visual iteration are part of the loop. It makes it the worse fit when the Python file is the source of truth, because every canvas edit becomes a re-export and a diff you have to reconcile by hand. There is no round trip documented in the README: edits to the generated Python do not flow back into the workflow.

A second alternative is running ComfyUI as a service and submitting prompts over its HTTP API. That keeps caching, queueing and model residency in ComfyUI, which the exported script explicitly does not do. The trade is that you now own a running ComfyUI instance and its lifecycle, rather than a file you can commit.

Maintenance, licence and what an upgrade costs you

The repository is not archived, and the last push was on 2026-05-10. The most recent release listed is v2.1.0 from 2026-03-30, preceded by v2.0.0 (labelled Readability Refactor) on 2026-03-29 and v1.3.2 on 2026-03-28. The version in pyproject.toml matches v2.1.0.

The dependency surface is small: pyproject.toml declares black, and requirements.txt lists the same single package. requires-python is ">=3.12", so the extension will not install on older interpreters, and the README repeats that constraint in its troubleshooting section. The only runtime coupling that matters is ComfyUI itself, which is not a declared dependency because the extension expects to find it through COMFYUI_PATH or a parent directory.

The licence is MIT, declared both in the LICENSE file at the repository root and in pyproject.toml. MIT is permissive, so redistributing generated scripts is not the question; the question is whether the generated script pulls in ComfyUI code that carries its own terms. That is a question for whoever reviews the deployment, not something this article can settle.

Upgrade cost is concentrated in two places. A release that changes the generated script's structure will invalidate any local edits you made to an exported file, since the export is a snapshot rather than a template. A release that changes how the extension is discovered under custom_nodes will require the reinstall described above, in the interpreter that launches ComfyUI.

Editorial conclusion

Adopt it if you build graphs by hand in ComfyUI and want a checked-in Python artifact you can edit and rerun, and you are willing to keep a ComfyUI checkout next to it. Do not adopt it if you need a long-lived prompt server, per-call caching, or CLI arguments generated from your widgets; the README states the generated script is a workflow export and that exported scripts are single-shot runners. Before committing, verify three things: that the environment launching ComfyUI is the one where you ran the install, that COMFYUI_PATH resolves to the ComfyUI tree, and that a generated script still runs after you change a node in the original graph, because the export is a snapshot and does not track later edits.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pydn/ComfyUI-to-Python-Extension on GitHub
4. README
5. Releases