Error "401: Unauthorised" when accessing the Configurator page

If I click on the configurator button (spanner) on the home screen the browser goes to
http://hassio.local:8123/configurator but the area where the configuration options would normally appear just contains “401: Unauthorized”. The browser cache has been completely cleared and the hassio pi rebooted but this makes no difference. If I press refresh then it tries to display a blue header but then just reverts to a white page with “401: Unauthorized”. Anyone got suggestions as to what else I can clear or try to get this working again?

The problem started when I moved the HA to my new house and changed from accessing the HA from a Windows 10 PC (chrome browser) to accessing via a Teamviewer running on a Pi (chromium browser). The HA is running on another Pi. The IP address of the HA has not changed.

1 Like

Complete guess, but I would assume Configurator by default only permits localhost (

Go look up the documentation to see if you can whitelist other IPs.

I guess my issue is the same as this one Help - All addon with Ingress: 401 Unauthorized

Some extra info, I installed the the File Editor addon which added a button on the left that resolves to the address http://hassio.local:8123/core_configurator when clicked this also resolves to “401: Unauthorized”. However, if I return to the File Editor addon under the Supervisor page and then click on the “Open Web UI” then this works as expected and gives a file editor but resolves to address http://hassio.local:8123/hassio/ingress/core_configurator. I tried adding manually /hassio/ingress to the configurator URL (http://hassio.local:8123/hassio/ingress/configurator) but this too eventually failed as it did not resolve and resorted to http://hassio.local:8123/configurator which failed as expected.

Unfortunately I have the same problem here. Started a new raspi hassio and have many problems with 401.
However I noticed that my problem only occurs on Opera- and UR-browser. Using Firefox or windows-Edge I don’t see the problem.
So it seems to be related to the browser in combination with Home Assistant, but I have no idea of a solution except using another browser :frowning:

Just FYI

I have issue with Chrome all of a sudden as of last month or two… Safari on my mac works well.

Running NUC and did multiple restore from snapshots old and new… nothing worked and then saw the last post and tired Safari… and it works…

I usually have HA config shared with IP restriction and edit via Textedit. The configurator is convenient when I want to tweak something without really diving in.

1 Like

hello in my case i’ve Chrome.
I have solved this problem by deleting my history and cookies.

I hope this will help you


Also had the “401: Unauthorised” problem for the “File Editor” in chrome after reseting my hass on a RPi. I did not have to reinstall Chrome but delete all site data and settings for sites. After that File Editor worked again.


I confirm it looks like a cookie issue. Running in incognito mode worked for me, so if you delete all site data and settings for sites you should be good


Just to add a bit more. Having the same issue here. Actually tried to reinstall HASSIO several times before giving up on that path. Can reproduce 401: Unauthorized reliably with at least File Editor and deconz addons. Console says WARNING (MainThread) [supervisor.api.ingress] No valid session None each time I try to access these endpoints.
When trying Edge instead of Firefox, I can suddenly access the addon. What is the issue here?

as usually, 5min after resorting to posting in a forum I found a clue here
turns out hassio isn’t friends with firefox’s enhanced tracking protection


Also getting 401: Unauthorized often I have access to home assistant (sometime it’s doesn’t work with the app or safari but it’s work with Firefox) but then when I’m trying to use a add-on like the text editor or SSH I have this error.

do anyone use Cloudflare Access I wonder?

Turning of the tracking protection for home assistant in Firefox did it for me! Thanks for the solution.


To disable Enhanced Tracking Protection click the shield to the left of the address bar.



Just had the same issue on Chrome after installing NGINX and you’re correct, removing cookies did the trick.

1 Like

In my case I found the problem began once I installed the duckduckgo essentials privacy extension in my browser (Edge). Just in case for you to check. Removing extension did the trick.

This helped me. Thanks.

I’m facing this in Chrome.
I uninstalled NGINX, cleared cookies and cache several times, disabled all extensions, disabled Chrome security features, everything I could find. Doesn’t work.

As soon as I open in incognito, it works perfect. Also in Edge. I can’t find what exactly is causing this for me. Any ideas?

Just did an update from 2021 to 2023 in virtualbox. I have duckdns and had to change the ip passthrough of my router to the new instance of HA 2023. didn’t notice at first, but now terminal and file editor don’t work. Did as instructed and flushed dns, cleared browser cookies and cache and did not work. Opened an incognito tab in chrome and work fine. Still need to figure out what I did, I’m sure something during my transition, but at least I have access.


I also attempted to port forward using duckdns and let’s encrypt. Had trouble using duckdns and didn’t want to port forward because of the security risks. I reverted my set up and noticed the same errors with file system and terminal. I was able to fix error caused from duckdns.

I went to chrome settings => Privacy and security => Site settings => View permissions and data stored across sites. I purged all sites
with Home Assistant in the name, reloaded and everything worked.

Not sure why but there were multiple sites with similar url to the local one had been using before trying to implement duckdns. I think these site had something to do with the errors. Once I cleared the data from these sites everything went back to normal.


Something that worked for me was opening the application from a browser in unknown mode

The problem occurs in the files stored by the web page in my case. clearing the cache was the solution

1 Like

2024: confirmed