Subprocess and Process Spawning#

Overview#

comfy-cli launches ComfyUI and its toolchain by constructing subprocess commands with a resolved Python interpreter. The three central files are:

• comfy_cli/resolve_python.py — interpreter resolution logic
• comfy_cli/command/launch.py — foreground and background process spawning
• comfy_cli/uv.py — dependency management subprocesses (pip/uv invocations)

Python Executable Resolution#

All subprocess commands that touch the ComfyUI workspace must use the workspace-local Python, not sys.executable. When comfy-cli is installed via pipx or uv tool, sys.executable points to the tool's own isolated venv — using it directly would install packages into the wrong environment. PR #375 introduced resolve_python.py to fix this.

resolve_workspace_python(workspace_path) picks the interpreter in this priority order:

1. $VIRTUAL_ENV environment variable (active virtualenv)
2. $CONDA_PREFIX (active conda environment)
3. Workspace-local .venv or venv directory
4. Fallback to sys.executable

On Windows, the binary path is Scripts/python.exe; on POSIX it is bin/python 1.

ensure_workspace_python(workspace_path) goes further: if the process is running from an isolated tool environment (pipx, uv tool) or from a PEP 668 externally-managed system Python (e.g. Ubuntu 24.04), it auto-creates a .venv inside the workspace via create_workspace_venv() before returning the interpreter path.

Key callsites: launch.py calls resolve_workspace_python at the top of launch() before every subprocess invocation. uv.py's DependencyCompiler and all static methods accept an executable parameter (defaulting to sys.executable at definition time but always overridden at callsites) 2.

Foreground Launch#

launch_comfyui(extra, frontend_pr, python) runs ComfyUI in the foreground using subprocess.run:

subprocess.run([python, "main.py"] + extra, env=new_env, ...)

• The working directory is already set to the workspace via os.chdir() before calling this function 3.
• A __COMFY_CLI_SESSION__ env var is injected for session tracking; PYTHONENCODING=utf-8 is set unconditionally 4.
• Under --json mode, the child's stdout is redirected to stderr to avoid polluting the machine-readable envelope on stdout 5.
• The loop re-runs subprocess.run to support ComfyUI's reboot-file mechanism 6.

Background Launch#

comfy launch --background follows a two-process relay:

1. Monitor process (background_launch → launch_and_monitor): spawns a child comfy launch process with COMFY_CLI_BACKGROUND=true set, then tails the logfile waiting for the "To see the GUI go to:" success marker.
2. Worker process (launch_comfyui with COMFY_CLI_BACKGROUND set): uses subprocess.Popen with stdout=PIPE / stderr=PIPE and redirector threads to avoid broken-pipe errors on background stdout/stderr 7.

Platform differences in Popen:

• Win32: shell=True, creationflags=subprocess.CREATE_NEW_PROCESS_GROUP 8
• POSIX: plain Popen without shell 9

The child's stdout/stderr are redirected into a workspace logfile (<workspace>/user/comfyui_<port>.log, truncated on each launch) rather than being held in memory. The monitor tails that file to detect the success line; after it exits, the child continues writing to the same fd 10.

The log file is opened with O_NOFOLLOW and 0o600 permissions to defend against symlink attacks on shared hosts 11.

Exits use os._exit() (via _hard_exit()) rather than sys.exit() because normal exit handlers cannot run once the redirector threads are live.

Python 3.14 Compatibility: asyncio.run()#

Issue: comfy launch --background crashed on Python 3.14 with RuntimeError: There is no current event loop in thread 'MainThread' 12.

Root cause: The old code in background_launch() used the two-step pattern:

loop = asyncio.get_event_loop()
log = loop.run_until_complete(launch_and_monitor(cmd, listen, port))

asyncio.get_event_loop() implicitly created an event loop on the main thread in Python ≤ 3.13, deprecated in 3.10/3.12, and removed in 3.14 12.

Fix (PR #481): Replaced with the single modern idiom:

log = asyncio.run(launch_and_monitor(cmd, listen, port))

asyncio.run() creates, runs, and closes its own loop — universal from Python 3.7 through 3.14+. launch_and_monitor uses only subprocess.Popen + threads internally (no asyncio tasks or async generators), so a fresh loop lifecycle is equivalent 13. This was the only asyncio.get_event_loop() call site in the codebase.

Do not reintroduce asyncio.get_event_loop() or add sys.version_info guards — asyncio.run() is already universal.

Dependency Management Subprocesses (uv.py)#

comfy_cli/uv.py wraps uv pip compile, uv pip install, uv pip sync, and pip wheel as subprocess calls using the workspace-resolved executable:

• _run(cmd, cwd) — subprocess.run with capture_output=True
• _check_call(cmd, cwd) — subprocess.check_call; on uv pip install/sync failure, prints a hint about UV_LINK_MODE=copy for network filesystems (RunPod, NFS)
• ensure_pip(python) — idempotent pip bootstrap; if the workspace venv has no pip (common in uv-managed venvs), runs uv pip install pip or python -m ensurepip --upgrade

All DependencyCompiler static methods prefix their command with [str(executable), "-m", "uv", "pip", ...], so the target interpreter is always explicit 14.