run_workspace
Queues the active ComfyUI graph for execution, mirroring the browser's Queue Prompt, and mirrors progress events or returns the prompt_id for async monitoring.
Instructions
Press Queue Prompt in the browser and watch the run from here.
The tab queues its own canvas, unsaved edits and all, so everything reacts the way it does when the button is clicked by hand: nodes light up, progress bars fill, sampler previews appear, and the result lands in the node that produced it. Nothing is written to the workflows directory. Use this when the user is working on a graph in front of them; use run_workflow for a file.
It has to be the tab that queues. ComfyUI addresses execution events to whoever
submitted the job, and the frontend only tracks jobs it queued itself, so a
graph submitted from here leaves the canvas reporting someone else's run. The
events are copied back to this server so progress is still reported; if that
copy cannot be set up the run still happens and progress_mirrored says it did
not, which is the one case where get_progress goes quiet.
Two consequences of it being the real button. Widget callbacks run, so a seed
set to randomize advances on its own - no two runs are alike unless the
canvas says so. And the graph is not rewritten on the way out: a PreviewImage
stays a PreviewImage and its result lands in temp/, which ComfyUI clears on
restart. Change the node itself with set_workspace_values to keep it.
There is no params argument on purpose: set_workspace_values makes the edit,
reports what changed from and to, and leaves it as one Ctrl+Z. Folding that into
a run would hide an edit to the user's canvas inside a call that reads as
read-only, and spend GPU minutes before anyone had seen the change.
Muted and bypassed nodes are dropped when the graph is converted, so a muted
SaveImage produces no output at all. get_workspace_graph lists both under
issues, which is worth a look when a run finishes with nothing to show.
Args: wait: wait for the run to finish. When False, returns the prompt_id immediately and keeps watching in the background, so get_progress(prompt_id) reports steps as they happen. Prefer this for anything slow - waiting blind is what makes a caller mistake a working generation for a hung one. timeout: seconds to wait before giving up on a running job. client_id: which tab to run; defaults to the most recently focused one.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | ||
| timeout | No | ||
| client_id | No |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||