frontend: Enable cluster deletion in browser

[alokdangre]

Summary

This change enables the deletion of clusters when running Headlamp in a browser, provided that dynamic cluster management is enabled in the backend configuration.

Previously, cluster deletion was restricted to the Electron app.

Related Issue

Fixes #3053

Changes

• Adds isDynamicClusterEnabled to the Redux config state.
• Updates ClusterContextMenu to check this flag in addition to isElectron.
• Ensures the X-HEADLAMP_BACKEND-TOKEN is set correctly in development mode for API requests.

Steps to Test

1. Go to view cluster
2. click on three dots
3. click delete
4. confirm

Screenshots (if applicable)

Screen.Recording.2026-01-27.114635.mp4

[alokdangre]

@illume ptal

[Copilot]

Pull request overview

This PR enables cluster deletion in browser mode when dynamic cluster management is enabled in the backend configuration. Previously, cluster deletion was restricted to the Electron desktop app only.

Changes:

• Added isDynamicClusterEnabled flag to Redux config state to track backend dynamic cluster support
• Updated ClusterContextMenu to show delete option when either running in Electron or when dynamic clusters are enabled
• Modified backend token initialization to support development scenarios via environment variable

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
frontend/src/redux/configSlice.ts	Adds isDynamicClusterEnabled field to ConfigState and updates setConfig reducer to handle the new optional parameter
frontend/src/redux/configSlice.test.ts	Adds test case to verify setConfig properly handles isDynamicClusterEnabled parameter
frontend/src/helpers/getHeadlampAPIHeaders.ts	Initializes backendToken from REACT_APP_HEADLAMP_BACKEND_TOKEN environment variable for development scenarios
frontend/src/components/App/Home/ClusterContextMenu.tsx	Updates cluster delete menu item visibility logic to check isDynamicClusterEnabled in addition to isElectron()

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[illume]

Thanks for this.

I see this issue in the filing GitHub check:

src/components/project/ProjectCreateFromYaml.stories.tsx:35:7 - error TS2741: Property 'isDynamicClusterEnabled' is missing in type '{ clusters: null; statelessClusters: null; allClusters: any; settings: { tableRowsPerPageOptions: number[]; timezone: string; useEvict: true; }; }' but required in type 'ConfigState'.

35       config: {
         ~~~~~~

  src/redux/configSlice.ts:49:3
    49   isDynamicClusterEnabled: boolean;
         ~~~~~~~~~~~~~~~~~~~~~~~
    'isDynamicClusterEnabled' is declared here.

[error] Found 1 errors and 2 warnings

Please also consider the open comments?

[alokdangre]

@illume fixed the changes ptal

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[joaquimrocha]

I am not sure we should make this dependent on the dynamic clusters being available because the dynamic clusters don't have much to do with being able to delete a cluster from the kubeconfig.
Still we should make sure that we do not offer this option (and especially that we do not effectively remove clusters) when Headlamp has been deployed with kubeconfig as an option. We need to be extremely cautious with this, as we don't want users removing clusters from their company-deployed Headlamp.

So maybe this means we should have a flag --allow-kubeconfig-removal or something, which would be false by default, but we'd set it to true when developing and when running the app (which would work in headless mode).

@sniok / @illume , WDYT?

BTW, there was already this PR in draft from last year: #3339

[alokdangre]

I am not sure we should make this dependent on the dynamic clusters being available because the dynamic clusters don't have much to do with being able to delete a cluster from the kubeconfig. Still we should make sure that we do not offer this option (and especially that we do not effectively remove clusters) when Headlamp has been deployed with kubeconfig as an option. We need to be extremely cautious with this, as we don't want users removing clusters from their company-deployed Headlamp.

So maybe this means we should have a flag --allow-kubeconfig-removal or something, which would be false by default, but we'd set it to true when developing and when running the app (which would work in headless mode).

@sniok / @illume , WDYT?

BTW, there was already this PR in draft from last year: #3339

that's very nice point, it seems good to me, im implementing the suggested review
also the draft pr was stale from long time, and also the issue was unassigned from that user so i took the issue

[joaquimrocha]

Changes look good. I was gonna suggest we use ALLOW_KUBECONFIG_CHANGES as the removal alone is too broad, but then I double checked how we are allowing adding new clusters to the kubeconfig just on the condition we are running in Electron, and now I am having doubts if we need a new flag or we just use isElectron.
I think in the past we refrained from removing clusters from the kubeconfig as this could surprise the user, but as Headlamp has become more established, I wonder if we have enough support that it's a major Kubernetes UI and thus it's expected that it changes the kubeconfig.

So to be clear: either we add a new "AllowKubeConfigChanges" flag, or we do not any new flags and allow deleting clusters from the kubeconfig files only when isElectron() is true.

Any thoughts @sniok / @illume ?

[sniok]

or we do not any new flags and allow deleting clusters from the kubeconfig files only when isElectron() is true.

doesn't it already work like this? we can delete clusters in the app

[alokdangre]

or we do not any new flags and allow deleting clusters from the kubeconfig files only when isElectron() is true.

doesn't it already work like this? we can delete clusters in the app

yes its the logic currently used in app, but i added a flag in this pr, so i will remove the flag from the electron app

[illume]

Thanks for making those changes. It got me thinking about something else...

Can we enable this flag by default in "headless" mode? See the app/electron/main.ts for headless mode.

Since this is a local thing, if we can enable this functionality for headless mode it will more closely match the abilities of the app. Since the security context of these two modes are pretty much the same... they are both app mode run by an individual.

[alokdangre]

Thanks for making those changes. It got me thinking about something else...

Can we enable this flag by default in "headless" mode? See the app/electron/main.ts for headless mode.

Since this is a local thing, if we can enable this functionality for headless mode it will more closely match the abilities of the app. Since the security context of these two modes are pretty much the same... they are both app mode run by an individual.

done

[illume]

Thanks! 🎉

(I’ll leave this one open to give the others a chance to have a look)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alokdangre, illume

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [illume]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment