mirror of
https://github.com/Comfy-Org/desktop.git
synced 2026-11-04 23:47:43 +00:00
[GH-ISSUE #1595] [Bug]: ComfyUI Desktop don't close well #472
Labels
No labels
area: desktop-app
Bounty
bug
bug-cop:answered
bug-cop:response-received
component: installer
component: preload
custom node
dependencies
Design
documentation
duplicate
enhancement
expected
frontend
good first issue
installation
Low-Priority
performance
Planned
platform: cross-platform
platform: windows
Potential Bug
Potential Bug
pull-request
question
refactor
Release
stale
User Support
V1
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Comfy-Org/desktop#472
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @msnbcorp on GitHub (Feb 7, 2026).
Original GitHub issue: https://github.com/Comfy-Org/desktop/issues/1595
App Version
0.8.3
Expected Behavior
The application process should kill itself after exiting ComfyUI desktop
Actual Behavior
Hi,
I don't know why but ComfyUI desktop seems to have a bug when closing. If you look at the process the comfyUI process still exist after exiting.
After several launch/exit loop you can have multiple comfyUI process at once.
I don't know why the bug exist, but here is the report :)
Steps to Reproduce
Just quit ComfyUI desktop on windows and search for the process in the windows task manager (details).
Debug Logs
Browser Logs
No response
Settings JSON
No response
Other
No response
┆Issue is synchronized with this Notion page by Unito
@coderabbitai[bot] commented on GitHub (Feb 7, 2026):
⚠️ Possible Duplicate Issue(s)
📝 Issue Planner
Generate an implementation plan and prompts that you can use with your favorite coding agent.
🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
@dosubot[bot] commented on GitHub (Feb 7, 2026):
This is a known issue—there are several reports that ComfyUI Desktop sometimes leaves lingering ComfyUI (Python) processes running after the app is closed on Windows, which can accumulate over multiple launch/exit cycles. The app is designed to kill the server process on exit, but the shutdown logic doesn't always succeed, especially in the Electron environment on Windows. Maintainers have acknowledged the bug and are working on fixes, but no definitive solution is documented for version 0.8.3, and recent updates haven't fully resolved it yet (source, source, source).
Some users have tried disabling the "Show confirmation dialog when closing" setting to fix related freeze issues, but this doesn't solve the lingering process problem (source). For now, you may need to manually end leftover processes in Task Manager. Keep an eye on future updates and changelogs for improvements to process shutdown and cleanup.
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
@davehornik commented on GitHub (Feb 9, 2026):
I can confirm this issue on:
After closing the Desktop app, two orphan Python processes remain running:
PID 52152 - G:\comfyUI.venv\Scripts\python.exe ... main.py --port 8190PID 51776 - C:...\uv\python\cpython-3.12.11\python.exe ... main.py --port 8190Both are full ComfyUI server instances (one from the venv, one from uv's Python) that keep the port bound and consume ~265 MB of RAM + GPU memory.
Impact beyond resource waste: This also breaks extensions that use IPC connections to external apps. For example, I'm developing a Discord Rich Presence extension using pypresence - because the Python process survives app close, the Discord IPC pipe stays open and the activity status persists in Discord indefinitely after closing ComfyUI.
The
before-quithandler's 10-second SIGTERM timeout appears insufficient on Windows. Ataskkill /F /PID(TerminateProcess) fallback after the timeout would fix this reliably.Workaround: Manually killing the processes via Task Manager or
taskkill /F /PID <pid>.Also can confirm that disabling "Show confirmation dialog when closing" didn't do nothing.
@h-schoenberger commented on GitHub (Feb 18, 2026):
Regarding "The app is designed to kill the server process on exit, but the shutdown logic doesn't always succeed".
This is not true.
It it not the python executable that is still running.
It is the powershell.exe that prevents ComfyUI from closing.
When I kill it, all ComfyUI proceses close.
@trashkollector commented on GitHub (Feb 18, 2026):
what powershell? comfy desktop is standalone app. Yes, you can see python.exe process in task manager
@h-schoenberger commented on GitHub (Feb 18, 2026):
Not so "stand alone" as the main comfyUI.exe starts 9 other processes...
The powershell.exe that was started by comfyUI.exe?
Please do not use the Task Manager, use some other app that shows the process tree like Process Explorer:
Yes, I do not understand why it starts powershell.exe as well, but it does. But it also starts conhost.exe with flags like "--signal 0xe60 --server 0x5c8" and I do not see any reason for that as well. But again, it does.
Ok, digged a bit into the main.cjs of ComfyUI to find out why:
Location A:
const WMI_PNP_DEVICE_ID_QUERY = 'powershell.exe -NoProfile -NonInteractive -Command "[Console]::OutputEncoding = [System.Text.UTF8Encoding]::new($false); Get-CimInstance Win32_VideoController | Select-Object -ExpandProperty PNPDeviceID | ConvertTo-Json -Compress"';
Location B:
function getDefaultShell() {
return
${process.env.SYSTEMROOT}\\System32\\WindowsPowerShell\\v1.0\\powershell.exe;And getDefaultShell() is used for getPypiFallbackIndexUrls() and the class Terminal.
@h-schoenberger commented on GitHub (Feb 18, 2026):
PS:
I see two options to fix the bug:
Recommended:
Add UI Message Dialogs or other break points to the source to start comfyUI.exe in "chunks" and make the chunks smaller and smaller until you to see which function starts this powershell.
Then fix it. Verify that the process is killed.
Powershell might wait for input or ComfyUI might wait for powershells output.
Common issue.
As a quick solution.
Just implement some "KIll All" like this one?
(not my node, just an example)
import { app } from 'electron';
import { exec } from 'child_process';
// This ensures that when the main window is closed,
// all child processes started by this PID are terminated.
app.on('will-quit', () => {
if (process.platform === 'win32') {
// Forcefully kill any processes that were started by us
// /T kills child processes, /F is forceful
exec(
taskkill /pid ${process.pid} /T /F, (err) => {if (err) console.error("Error during final cleanup", err);
process.exit(0);
});
}
});
@trashkollector commented on GitHub (Feb 19, 2026):
hmm.. I see this
@h-schoenberger commented on GitHub (Feb 19, 2026):
Then it depends on the Windows version or the hardware or drivers that powershell does not close.
Perhaps a requested output is not generated on my machine because something does not exist and therefore ComfyUI waits forever.
Just to confirm: Do you get the issue that ComfyUI.exe does not close?
@wc723 commented on GitHub (Feb 20, 2026):
This problem has existed for about six months, and it's unlikely that it will be fixed anytime soon.
@davehornik commented on GitHub (Feb 20, 2026):
Yea... Since I am using ComfyUI thru custom Claude MCP I had to make curl controller to
/start/statusand/stopwhich kills the entire tree.@Zervox commented on GitHub (Mar 16, 2026):
So atleast one thing that is guaranteed to trigger it for me is whenever I restart the backend(remember to refresh the browser popup) after an extension install or uninstall.
@mzly1212 commented on GitHub (Apr 6, 2026):
Has this issue not been resolved yet? I had been using the desktop version 0.4.x previously, and today, I upgraded the desktop to 0.8.x to use the Flux model, and this problem occurred.
(At first, I just noticed that every time I opened the app, it always displayed a new workflow, which did not happen in the previous 0.4.x version, and then I noticed that the app did not exit properly, with many processes still remaining.)