Comfy-Org/ComfyUI_frontend

[Feature Request]: Allow disabling sidebar tabs, topbar menu items, setting panels, etc. via hidden settings

Open

#3,388 opened on Apr 10, 2025

View on GitHubContributor guide
 (5 comments) (0 reactions) (0 assignees)TypeScript (610 forks)github user discovery
enhancementhelp wanted

Repository metrics

Stars
 (1,838 stars)
PR merge metrics
 (Avg merge 4d 21h) (881 merged PRs in 30d)

Description

Is there an existing issue for this?

  • I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

There are many orgs deploying ComfyUI_frontend as part of a service. They want the ability to disable certain functionalities when serving the client view. For example:

  • they may want to use their own internal workflow storage/sharing system and therefore disable the workflow sidebar
  • they may want to disable topbar menu items to prevent saving things to comfy instance disk
  • they may want to disable opening settings or changing hotkeys to prevent workarounds

See examples: https://www.seaart.ai/workflow, https://tensor.art/workflow

Proposed workflow

  1. Create hidden settings that offer easy way to configure which commands, sidebar tabs, topbar menu items, settings panels, settings, etc. are disabled
  2. If something is disabled, prevent the associated UI components from loading and also prevent it from being loaded via workarounds e.g., using commands

Additional information

No response

┆Issue is synchronized with this Notion page by Unito

Contributor guide

Research direction
Explore the codebase to understand how sidebar tabs, topbar menu items, and settings panels are registered and rendered. Look at existing hidden settings for patterns and how they disable features. Identify where to add new hidden settings and how to prevent disabled UI components from loading.
Tech stack
typescript
Domain
frontend
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
TypeScriptGit
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
55