Proposal: Support dynamic combo box inputs with force_input in execution.py

[Jonathon-Doran]

I'm developing a custom node that dynamically updates a combo box based on another field (like a file path). The dropdown values come from a fetch() call in the frontend and aren't known at the time INPUT_TYPES() is evaluated.

To support this, I've added a small patch to execution.py that allows the validation to be bypassed when a force_input flag is set. Specifically, the patch looks for a force_input key in the options dictionary (i.e. the second element of the (list[str], options) tuple returned by INPUT_TYPES).

The check looks like this (inside the validate_inputs() logic for combo types):

    combo_options = input_type

    force_input = (
        isinstance(info, tuple)
        and len(info) == 2
        and isinstance(info[1], dict)
        and info[1].get("force_input", False)
    )

    if not force_input and val not in combo_options:
        # existing validation error block...```
        
When force_input is True, validation for val not in combo_options is skipped — this allows dynamic or user-entered values to be accepted without triggering validation errors.

This is useful for allowing combo boxes to be populated based on other widget input, remote API results, non-enumerable large datasets (like directory listings)

My questions:

Is there interest in making this official?  Would a PR be considered?  Is there a preferred alternative for this use case?

Thanks in advance.

[christian-byrne]

There's a way to make combos be populated by requesting a route:

ComfyUI/nodes.py

Lines 1747 to 1766 in 27870ec

	class LoadImageOutput(LoadImage):
	@classmethod
	def INPUT_TYPES(s):
	return {
	"required": {
	"image": ("COMBO", {
	"image_upload": True,
	"image_folder": "output",
	"remote": {
	"route": "/internal/files/output",
	"refresh_button": True,
	"control_after_refresh": "first",
	},
	}),
	}
	}
	DESCRIPTION = "Load an image from the output folder. When the refresh button is clicked, the node will update the image list and automatically select the first image, allowing for easy iteration."
	EXPERIMENTAL = True
	FUNCTION = "load_image"

Is that what you meant or would you want to do differently?

[Jonathon-Doran]

Thanks, Christian. I appreciate the pointer to the remote route setup. I've experimented a bit with that mechanism. It's useful for fetching combo box options dynamically, but I may be misunderstanding how it's meant to work. In my testing, even when the UI fetches updated values from a server route, execution fails if the selected value wasn't in the original list defined in INPUT_TYPES. It looks like validation during execution still checks against the static list declared at node definition time, not the values fetched by the frontend. That makes it difficult to support cases where the available options depend on earlier inputs, like selecting a subfolder based on a base path, or dealing with user-provided paths that aren't known in advance. To work around it, I patched execution.py to skip the value check if a force_input flag is set on the combo. That allows the node to execute successfully with dynamic values, though it's not ideal and not something I'd want to rely on long term. If I'm missing a better way to handle this, I'd be glad to hear it. Mostly I'm just trying to build nodes that can adapt to the user's environment without being tightly coupled to a single folder structure. Thanks again for the response. Edit: Removed message thread

[christian-byrne]

Hi @Jonathon-Doran! I've been looking into your proposal and I'm trying to understand the specific scenario where the current validation fails.

The LoadImageOutput combo population via remote routes does seem to work fine w.r.t validation:

"image": ("COMBO", {
    "remote": {
        "route": "/internal/files/output",
        "refresh_button": True,
        "control_after_refresh": "first",
    },
}),

Could you share a specific code example of a node that currently fails validation? I want to make sure I understand exactly what scenario the force_input flag would enable that isn't currently possible.

[Jonathon-Doran]

Sorry for the delay. I am swamped at the moment with emergencies, but I promise that I will get back to you. I have tested your solution and can explain the difference. I am putting together a clean minimal example rather than sharing half-finished nodes with you. Edit: Removed message thread

[Jonathon-Doran]

Hi Christian, thanks again for following up. I was able to look into this and build a couple of nodes to share. You're right that LoadImageOutput works well with remote combos using a route defined directly in INPUT_TYPES. That model is fine when the options are relatively stable and predefined. The issue I'm pointing out shows up in a different pattern: One where the combo box values depend on another input and change dynamically at runtime. In the demo, there are two nodes, and the distinction between them is important. The RemoteComboNative node uses a remote combo via the standard ComfyUI pattern in INPUT_TYPES. It points to a route, and ComfyUI handles the population. That part works, but since the options come entirely from the internal combo system, the frontend cannot modify the values after initialization. Even if the underlying folder changes, and the backend returns new options, there's no way for the frontend to assign them to the combo. Any attempt to do so is ignored. You're effectively locked into whatever options ComfyUI originally recognized. In contrast, the NewCombo node defines its combo options as a simple list in INPUT_TYPES, and then replaces that list at runtime using the frontend. The key difference here is that the frontend can assign new values to comboWidget.options.values, and the UI will reflect them. This makes it possible to update the available folder list dynamically when base_dir changes. You'll see the combo box update and display the correct folders - the new values show up and you can select one. But this is where validation becomes a problem. Even though the UI shows the updated values and lets you select them, the backend still validates against the original list provided in INPUT_TYPES. Without force_input: true, the new selection will fail validation, because it wasn't part of the original list. With force_input: true, the system accepts values that weren't in the original combo definition, which is exactly what you need in this kind of dynamic scenario. So, the patch I proposed isn't about enabling remote combos in general. It's about making it possible to use runtime-defined combo options that change dynamically in response to other inputs, and having those values accepted by the system. The core behavior is already supported on the UI side, but it's blocked at the validation layer unless force_input is enabled and respected. I have a public repository with the demo nodes: https://github.com/Jonathon-Doran/remote-combo-demo The patch is needed for NewCombo to behave correctly, but it is helpful to see it with and without the patch (or force_input). Best, Jonathon Doran Edit: Removed message thread