[Bug] Combo image input is disabled when member models are hidden via disabledModels #6898

Client or integration

OpenCodex web dashboard (Combos editor) / Codex model catalog

Area

GUI / Combos / Catalog and model visibility

Summary

The Image / multimodal switch in the Combo editor becomes disabled when an image-capable provider model is hidden from the standalone model list using disabledModels, even when the Combo contains only that one model.

This breaks a useful configuration pattern: hide all raw provider models from the client model picker, and expose only curated Combo models, while retaining the underlying providers as Combo targets.

Reproduction

1. In OpenCodex v2.81.0, configure the built-in deepseek provider with deepseek-flash.
2. Create a Combo targeting deepseek/deepseek-flash (one target is sufficient).
3. In Models, disable the raw deepseek-flash model so that the client model picker shows only the Combo, not the raw provider model.
4. Reload the Combos editor and open that Combo.
5. Try to enable Image / multimodal.

Actual: The switch is grayed out and the UI says image support requires every selected target to advertise image input. This persists even with only deepseek/deepseek-flash selected.

Expected: The switch remains available because the selected Combo target still supports images. Hiding a raw model from the standalone client-facing model list should not erase its capability metadata for Combo derivation or editing.

Evidence from the live management API

GET /api/models in the affected installation returns:

[
  {
    "provider": "deepseek",
    "id": "deepseek-flash",
    "namespaced": "deepseek/deepseek-flash",
    "inputModalities": ["text", "image"],
    "inputModalitiesDeclared": ["text", "image"],
    "disabled": true
  },
  {
    "provider": "deepseek",
    "id": "deepseek-v4-flash",
    "namespaced": "deepseek/deepseek-v4-flash",
    "inputModalities": ["text", "image"],
    "disabled": true
  }
]

So the backend does recognize image support. The missing capability is introduced in the GUI's projection, not in DeepSeek's registry declaration.

Likely root cause (v2.81.0)

gui/src/pages/Combos.tsx:171-216 builds the models array consumed by the Combo editor, but skips disabled rows:

if (model.disabled === true) continue;

gui/src/combo-capabilities.ts:5-13 then checks each target against this already filtered array:

const model = models.find(
  (row) => row.provider === provider && row.id === modelId,
);
return !!model?.inputModalities?.includes("image");

Consequently, a valid hidden target is treated as missing/unknown and comboImagesSupported() returns false.

The default-model fallback in Combos.tsx:210-216 can also add a placeholder for the hidden model without inputModalities, which does not resolve the issue.

Suggested fix

Separate model visibility for the new-target picker from capability metadata for existing Combo members:

• Keep hidden model rows (including inputModalities) in the data available to Combo capability calculations.
• Preserve intended picker visibility separately (for example, carry a disabled field and filter only where selecting a new target).
• Continue rendering previously configured targets even when their standalone models are hidden.
• Add a regression test: a Combo targeting a model that advertises ["text","image"] continues to permit image input when its standalone model row is disabled: true.

This does not ask to re-expose disabled standalone models in Codex's public picker.

Operating system

Windows 11 Pro for Workstations (26H2, x86_64)

Version

OpenCodex v2.81.0. Reproduced on the web dashboard. No API keys or account data needed.