Javascript resources for HACS custom cards removed from dashboard after restart

Configuration Frontend
1

This is a very strange issue and I have spent a load of time investigating before posting here…

about 4 or 5 days ago I found that every one of my custom cards (all installed via HACS) were not displaying with the configuration error “custom element does not exist”

All my cards are installed correctly via HACS. Everything seems fine. Error log clean/normal.

I checked dashboard > manage resources and all of the card JS modules are missing. I restored a backup from 5 days ago and the resources are correctly listed. Did a restart and boom all gone and issue returns.

Not sure what to do and how to troubleshoot this from here. Looks to me like something is stopping the resources from loading when the system starts.

Any ideas or help appreciated.

Note also that I am seeing this issue across different browsers and computers and on my iOS companion app. I have cleared browser cache this has not helped

image
image722×863 43.1 KB

2

I should have mentioned this in my first post - I am running HA in a docker container.

Not sure if this is a clue but providing an update as this issue is driving me nuts :slight_smile:

Yesterday I re-downloaded all HACS dashboard integrations and this correctly populated resources for all custom cards and everything working correctly.

I upgraded to 2026.3.2 this morning and restarted HA container. Everything still working correctly. Then did a restart using HA GUI and the issue is back.

Every HACS javascript resource that starts with /hacsfiles/… gone.

What the heck is going on? Maybe something corrupt in my config?

3

After more searching I have found that I am not alone but this is clearly an issue that does not impact many installations/users.

4

Same here… I hope for a fix…

5

Same in my setup. Files are still available in config/www/community but references in the dashboard via /hacsfiles/ are gone.
Does anyone know more about the /hacsfile/ path? Seems to by something like an alias. If so, it could be, that it’s a timing issue during startup → Dashboard is checking the resources while hacs did not establish the /hacsfiles/-Alias… someting like that.

6

Update: seems, simply redownloading HACS itself (inside HACS) and rebooting fixed the issue.

7

No, I still lose all the resources when I reboot :smiling_face_with_tear:

8

same for me agin. I did some reboots yesterday evening. since than, It’s failing again.
My assumption is, that “/hacsfiles/” is something like a special mountpoint and is not available when the dashboard starts.
Any ideas which logging is relevant or needs to be turned on to confirm my theory?

9

just found this: Reboot unregisters frontend resources · Issue #165514 · home-assistant/core

10

I asked AI and got the following workarounds (1st one links to this discussion :wink: ):

What works right now (practical fixes)

:white_check_mark: Option 1: Reinstall HACS itself (quickest fix)

Many users report that re-downloading HACS from inside HACS fixes the alias registration permanently (for now):

  1. HACS → ⋮ → Re-download
  2. Restart Home Assistant

This worked for multiple users in March 2026. [community…sistant.io]

:white_check_mark: Option 2 (most robust): Switch to manual YAML resources

This avoids the broken persistence path entirely.

Add your resources explicitly in configuration.yaml:

YAML

lovelace:

mode: storage

resources:

  • url: /hacsfiles/mushroom/mushroom.js

type: module

  • url: /hacsfiles/button-card/button-card.js

type: module

Show more lines

:white_check_mark: Pros:

  • Survives restarts
  • No dependency on HACS re-registering resources
  • Recommended workaround by power users

:white_check_mark: Still fully supported by HA. [community…sistant.io]

:white_check_mark: Option 3: Use /local/ instead of /hacsfiles/

HACS installs cards to:

/config/www/community/<card>/

You can reference them directly:

YAML

  • url: /local/community/mushroom/mushroom.js

type: module

Show more lines

This bypasses the fragile /hacsfiles alias entirely.

Several users confirmed this avoids the issue. [community…sistant.io]