Using a server URL with pathname results in server not being added

[TomasHubelbauer]

Device model, version and app version

Model Name: MacBook Pro
macOS Version: 26.5 (25F71)
App Version: 2026.4.1
Safari Version: 26.5

Home Assistant Core Version
2026.5.1

Describe the bug
When using the macOS Home Assistant companion app downloaded from the App Store, in the onboarding flow when I select Enter Address Manually (because my HA instance is not on my local network, I am connecting to one that's accessible via Tailscale instead) and then enter a URL with a pathname, like /lovelace/0 instead of just the base URL, after signing in in the dialog for adding a new server, instead of the dialog closing and the server getting stored in the application's settings, the dialog web view loads to show the URL I entered.

To Reproduce
^

Expected behavior
I believe the app should be able to handle this and trim the path name automatically, or alternatively recognize the HA instance logged in successfully regardless of a path name in the URL.

Screenshots
N/A

[TomasHubelbauer]

I looked for guidance on LLM-assisted contributions and found this closed PR: home-assistant/core#167047. I'll assume LLM-assisted contributions aren't welcome so I'll stick to linking a commit I made in my fork which solves this for what I assume is the most common case: TomasHubelbauer@d597e26.

However, it works by replacing path instead of appending, which is a new behavior which would have happened to work in my case, but I can imagine someone running HA on a subpath which is a case that would have previously worked and now would have become broken.

I don't think we can reliably statically distinguish which behavior is correct for all cases just by URL manipulation, instead, the app might need to check that the provided URL is indeed a HA instance after it loads.

This is an interesting case because even with the path-having URL the Add Server dialog presented me with a login screen, because while I was deep-linkinh and not at /auth/authorize, the instance was still unathorized, so I got the login screen anyway.

But following the login, since I was not on /auth/authorize, the app did not get the right signal. Maybe it could detect successful login another/an additional way. Maybe by checking if the web view had any dropped cookies following the HA login? But this might go counter to the code-for-token exchange flow going on.

Just a few thoughts.