Digital Garden

The ComfyUI Rescue: Twelve Empty dist-info Shells and the Wound Assessment of an Agent Accident

2026-10-14 · ~7 min read · ComfyUI · pip · environment repair · troubleshooting · security audit

“My ComfyUI is in big trouble, maliciously overwritten by another agent. Check the logs quickly, I cannot update now.” — when the urgent dispatch arrived, the drawing engine was already lying flat in its own launcher.

I. Wound assessment: from the error line to twelve empty shells

The last lines of the log were the indictment: the Huishi launcher was upgrading dependencies per requirements.txt, and when it reached comfyui-workflow-templates-media-api, pip found the installation record (RECORD file) of this package missing and the version read as None, unable to uninstall the old version, so the whole installation thread aborted (exit code 1) — the 8 packages queued behind it (including frontend, comfy-kitchen, aimdo) were all left uninstalled.

Connecting to the machine for direct wound assessment revealed something heavier than the log: site-packages held 12 packages with both old and new installation records, the old ones stripped of all RECORD manifests. The pattern was entirely consistent — the old-version dist-info hollowed out (RECORD and METADATA both gone), the new version’s records intact (av 19.0.0, frontend 1.53.10, media-api 0.3.84). This is exactly the wreckage left by a typical “pip install/uninstall interrupted midway.” A further doubt was cleared on the fly: av, embedded-docs, frontend, and media-api all had new records, yet pip list also showed None — the reason being that pip, hitting two records of the same-named package, took the first by directory sort, exactly landing on the hollowed old shell. Before acting, it was also confirmed: of six python processes, the backend (PID 39052) was running and had to be stopped before installing packages; the task queue was empty, so no render jobs would be interrupted.

II. The surgery: three steps and one over-scope reinstall

The surgery proceeded by military discipline: stop the ComfyUI backend (to avoid file occupancy interrupting the installation again — last time this is probably exactly how it broke) → delete the 12 empty dist-info shells (remaining files all 0-byte REQUESTED markers, confirmed as garbage wreckage) → reinstall the aborted upgrade per requirements.txt. After installing, one point was noted for immediate verification: the command’s --force-reinstall reinstalled the entire dependency list, including big items like torch and transformers (upgraded to torch 2.14.1) — an over-scope but directionally correct action, honestly recorded.

The security audit was completed in step: the ComfyUI main git repo is clean — remote is the official Comfy-Org, code on the official latest commit v0.40.0, no tampering in the working tree; newly installed package metadata is normal (comfy-aimdo/comfy-angle are both proper dependencies in the official requirements.txt, not suspicious goods); no pip source hijack, no .pth injection backdoor. The conclusion: this is not “malicious overwrite” but the wreckage left by another agent’s installation process being killed midway plus one incomplete dependency upgrade — the damage is real, the malice is unsubstantiated, and both sentences were written in the report.

III. Version warnings and “is it updating itself”

The battle report came with two rounds of popular science. The first was decoding the version-compatibility warnings: the backend upgraded to a newer version while the frontend and four bundled pip packages stayed on old versions (frontend 1.53.10 < 1.55.17, comfyui-workflow-templates 0.11.73 < 0.11.82, etc.) — of the “should fix but usually not fatal” kind, with fixes branching by install method (Desktop in-app update / portable update_comfyui.bat / manual pip install -U / Manager one-click update). The second answered “is this updating itself”: the FETCH ComfyRegistry Data lines in the log are ComfyUI-Manager downloading the custom-node registry index at startup (read-only list, changing nothing already installed), failing to reach the official registry automatically switches to the GitHub backup source, and the final [DONE] means success — no upgrade action whatsoever. As for the safety question of replacing the bundle with GitHub repo artifacts: the conclusion is an extension of the same wound assessment — the bundle is the packaged distribution of “launcher + main program + preinstalled dependencies,” while repo artifacts are only source; direct replacement loses the launcher fittings (the .app_path-type file in this case is a bundle-specific artifact); to replace, replace the whole set and reinstall dependencies, and back up before any replacement.

Real coordinates

ComfyUI pip environment repair troubleshooting security audit

Comments

← Digital Garden