Noisy "Request received to refresh token for admin." logging in v5.28.0

[mpatfield]

Describe The Bug

I just upgraded to v5.28.0 and I'm seeing "Request received to refresh token for admin." in the logs every time I open a new window for the Homebridge UI. Authentication is disabled in my settings.

Not sure if this is indicative of some issue in auth, but at the very least can we please make these debug-level logs?

Thanks!

Logs

[8/17/2026, 11:40:59 AM] [Homebridge UI] Request received to refresh token for admin.
[8/17/2026, 11:42:37 AM] [Homebridge UI] Request received to refresh token for admin.
[8/17/2026, 11:44:03 AM] [Homebridge UI] Request received to refresh token for admin.

Config

I don't think this is applicable, but happy to share if desired

Homebridge UI Version

v5.28.0

Homebridge Version

v2.4.0

Node.js Version

v24.19.0

Operating System

Raspberry Pi OS / Raspbian

Environment Info

Using Docker

Raspberry Pi Model

Raspberry Pi 5

[lidonius1122]

The log line itself looks like harmless noise — it's the routine session-restore path, new in v5.28.0 — rather than something going wrong with your session. There's a small labelling regression behind why it reads so generically.

Why it fires. Since v5.28.0 the UI keeps the access token in memory instead of localStorage (7c6a31b5). Every fresh page load therefore starts without a token and exchanges the hb-refresh cookie for a new one via POST /auth/session. With auth off that's the only refresh call in play, so it works out to exactly one per new window or tab.

Why the message is generic. restoreSession() passes reason: 'session-restore', but refreshTokenLogMessage() only has cases for admin-guard, session-extension and profile-update, so it falls through to the default text. The other three reasons still print their own distinct lines — this one path lost its label when the session endpoint replaced the old bootstrap route, and #2972 later removed the hb-session-bootstrap case that used to cover it.

Why you're seeing it with auth disabled. The old bootstrap call was gated behind formAuth, so with auth off it never ran. loadToken() has no such gate. On the very first load there's no cookie yet, so the restore fails silently and /auth/noauth sets one; from the second window onwards the restore succeeds — and logs.

One thing worth flagging on the suggested fix: logger.debug() in this repo is gated behind UIX_DEBUG_LOGGING=1, so moving the line there makes it disappear entirely rather than making it quieter. Giving session-restore its own case and logging that one at debug level, leaving the three interactive reasons on log, would keep the distinction #2898 introduced while taking the routine page-load line out of everyone's log.

Happy to put that up as a PR if it's useful — it's a small change plus a test.