Desktop (0.1.7-rc.2): dsh://open ignores query parameters — please pass session=<id> through to the web app so notifications can deep-link to a conversation

[unifilitence]

TL;DR (EN)

The Windows shell registers a dsh:// protocol but treats every activation as a plain window focus (dsh://open). We ship a community notification plugin that pops native Windows toasts on turn completion and approval requests; clicking a toast can only bring the window up, not open the originating conversation. The web side already has everything needed to switch conversations (uiWorkspace.openSession), so the only missing piece is shell→web delivery of a session id. A reference Electron implementation (from a self-built shell we ran before migrating to the official desktop) shows a small, robust pattern: parse deep-link params, stash them in a pending slot with TTL, push-or-consume via the preload bridge, and let a plugin client call openSession. Feature request: either parse dsh://open?session=<id> and forward it, or expose an official notification/session-jump extension point for host plugins.

使用场景

• 本地/第三方插件在"回合完成、审批请求"等时刻弹出 Windows 原生 Toast（经官方壳 AUMID 显示为 DeepSeek Harness 身份）。
• 点击通知：期望回到发出通知的那条会话（多会话并行工作时尤其关键）。
• 现状：只能唤回窗口（dsh://open），用户需要自己在侧边栏翻会话。

现状证据（0.1.7-rc.2 官方安装版，Windows；抽取自安装产物，未做任何修改）

1. resources/app.asar 内 lib/main.js：
   • :11552 app.setAsDefaultProtocolClient("dsh")（打包态注册）。
   • :11553-11556 open-url 仅匹配 dsh://open / dsh://open/ → focusPrimaryWindow()，不解析任何参数。
   • :6788、:11681-11682 second-instance → focusOwner；激活 argv 未被消费（全文件仅 :10627 附近处理 --updated）。
2. lib/preload-app.cjs:789-821：暴露给网页的桥仅 dshOnboarding / __DSH_DIRECTORY_PICKER__ / __DSH_HOST_PATHS__ / dshDesktopBoot / dshPlatform / dshDesktop / __DSH_LOCALE__——没有通知或会话跳转通道；ipcMain.handle/on 通道全集（约 :6241-11369）中亦无 open-session 类通道。
3. 而"最后一公里"网页侧已经存在：@deepseek-ai/dsh-client-ui-workspace 暴露 uiWorkspace.openSession(target)（lib/client.js:819-821），官方侧栏即在调用（:4158-4160）。

→ 唯一缺的一环：把一个 session id 从壳送到网页。

请求（两选一或都做）

1. 最小改动：dsh:// 深链解析查询参数（如 dsh://open?session=<id>），聚焦窗口后把参数转发给网页——例如在现有桥上增加 onOpenSession(cb) / consumePendingOpenSession()（或挂进现有 dshDesktop 桥）。
2. 更通用：为 host 插件提供"通知跳转"官方扩展点：插件发起携带 session 目标的系统通知，点击后由官方壳负责激活并切换到该会话（插件不接触壳进程，避免各插件自造轮子）。

参考实现（自建壳已验证可行；Electron 同架构，迁移官方壳前我们即按此运行）

四段链路（真实实现节选，路径泛化）：

① 激活入口统一解析（second-instance / 冷启动 argv）

function onProtocolArgv(argv) {
  const arg = argv && argv.find((a) => /^dshdesktop:\/\//i.test(a))
  if (!arg) return null
  try {
    const u = new URL(arg)
    const sid = u.searchParams.get('session')
    return sid ? String(sid) : null
  } catch { return null }
}
// second-instance 处理器: dispatchOpenSession(onProtocolArgv(argv))
// 冷启动首实例:       dispatchOpenSession(onProtocolArgv(process.argv))

② 槽 + push 双通道（防"冷启动点击、窗口/页面未就绪"竞态与重放）

let pendingOpenSession = null      // { id, at }，consume 即清
let pageReadyForDeepLink = false   // did-finish-load 后置位
const PENDING_OPEN_TTL_MS = 120000 // 盖过冷启动会话列表 probe（约 60s）+ 页面加载；重放窗口限死 2 分钟

function dispatchOpenSession(sessionId) {
  if (!sessionId) return
  pendingOpenSession = { id: sessionId, at: Date.now() }
  if (pageReadyForDeepLink && mainWindow && !mainWindow.isDestroyed()) {
    mainWindow.webContents.send('open-session', sessionId)   // push：页面已就绪
  }                                                          // 未就绪 → 留槽等拉取
}

ipcMain.handle('dsh-consume-pending-open-session', () => {
  const v = pendingOpenSession
  pendingOpenSession = null
  if (!v || Date.now() - v.at > PENDING_OPEN_TTL_MS) return null  // 过期作废
  return v.id
})

③ preload 桥（sandbox:true + contextIsolation:true 下可用）

contextBridge.exposeInMainWorld('dshShell', {
  onOpenSession(cb) { /* ipcRenderer.on('open-session', (e, sessionId) => cb(sessionId)) */ },
  consumePendingOpenSession() { /* ipcRenderer.invoke('dsh-consume-pending-open-session') */ },
})

④ 网页端消费（插件 client：等会话列表就绪后跳转）

// inject: ['slots', 'uiWorkspace', 'sessions']（Service 型服务必须声明注入，软取可能拿不到）
// 收到 sessionId：等 sessions.list 快照 ready（400ms 重试，上限约 6s）→
//   uiWorkspace.openSession(sessionId)，降级 sessions.open(sessionId)
// openSession 同 id 幂等（官方 README 明示）→ push + consume 双通道重复送达无害
// push 送达后前端 consume 一次作 ack：防页面崩溃重载后旧深链重放

自建壳运行期实测要点：

• 槽 + push 双通道解决"冷启动点击、窗口/页面未就绪"竞态；TTL 把重放窗口限死。
• openSession 同 id 幂等 → 双通道重复送达无害。
• 会话列表未就绪时短暂重试即可覆盖冷启动场景；目标会话过老/不在列表时仍可尝试一次，失败仅告警。

我们插件侧已备好的消费设计

社区通知插件（dsh-notify-desktop，经官方"插件"页以 bundle 安装）已实现：回合完成/审批请求的 Windows Toast（<toast activationType="protocol" launch="dsh://open">，经官方壳 AUMID 显示为 DeepSeek Harness 身份）+ 语音提醒 + 审批旁路监听（waterfall 永远透传）。一旦上游提供 session 透传，client 半侧将按④的模式实现"启动对账补弹 + push 订阅"，即插即用。

环境

• Windows 11（build 10.0.26200）；DeepSeek Harness Desktop 0.1.7-rc.2（官方安装版；未修改 app.asar）。

---

中文 / English 回复都可以，谢谢！

[unifilitence]

补充两项复核结果（主帖发布后的再次人工核验，脚本可复算），并顺带提一个建议。

① 激活参数完全未被消费

lib/main.js 全文件 argv 仅出现 1 处（:10627 附近，--updated）；second-instance 处理器为 application.on("second-instance", focusOwner)（:6788），激活参数不经任何解析直达窗口聚焦。因此 dsh://open?session=<id> 这类深链即使发出，也不会命中 :11555 的全等匹配（连聚焦都不会触发）。

② 网页侧桥 key 全集（决定性层）

lib/preload-app.cjs:789-821 的 contextBridge.exposeInMainWorld 全集为：

dshOnboarding / __DSH_DIRECTORY_PICKER__ / __DSH_HOST_PATHS__ / dshDesktopBoot / dshPlatform / dshDesktop / __DSH_LOCALE__

——没有任何 session/open 通道；ipcMain 侧同样没有 open-session 类通道。网页端只能调桥内 API，所以"把 session id 送进网页"当前确实无路可走，主帖的判断以行号级证据成立。

③ 顺带建议：官方原生的"回合完成 / 需要审批"系统提醒

复核时再次确认：0.1.7-rc.2 的系统级通知只有强更提醒（:8347），回合完成 / 审批请求都不会产生任何 OS 通知——agent 阻塞等待批准时，用户不在窗口前就只能干等。而事件面其实已经齐了（turn/end 带 reason、approval/request waterfall、approval/asked+decided 审计对，主帖已引），官方只要加一个设置开关（如"回合完成时通知我 / 需要审批时通知我"）就能让所有用户受益，无需插件。

我们用插件方式验证了整条链路可行（Windows Toast + 语音 + 审批旁路透传），也踩平了几个细节：Toast 主体点击需要显式 activationType="protocol"（默认 foreground 只会激活 AUMID 关联应用）；借用系统 AUMID 时 body 点击不生效、来源名/图标也不对，需用应用自身注册的 AUMID。欢迎参考。深链透传若一起做，"通知点击直达会话"即成完整闭环。

④ 我们可以立即实测

我们挂着现成的 client 端消费设计（主帖④段：等会话列表就绪 → uiWorkspace.openSession，降级 sessions.open），官方出 nightly/修复后可立刻升级验证并反馈结果。

环境：Windows 11 (build 10.0.26200)；DeepSeek Harness Desktop 0.1.7-rc.2（官方安装版）。

[PerryLink]

请先确认你点的是哪个 scheme——内部转发那条路径是保留查询串的

1. 我核到的那段（内部 dsh-app:// 转发）

apps/desktop/src/main.ts:617-632 的协议处理里，dsh-app://app/... 的非静态资源路径交给：

return forwardWebRequest(request, hostUrl, hostCookie)      // main.ts:629

而 apps/desktop/src/web-document.ts:81-83 是这样重建目标的：

const target = new URL(host)
target.pathname = source.pathname
target.search = source.search        // ← 查询串是被显式带上的

⇒ 在 dsh-app:// 这条内部转发路径上，query 参数是被保留的。所以你报的"忽略 query 参数"如果出在这条路径上，我会意外。

2. 所以请先区分是哪一个

• dsh://open?...：这是外部深链（系统级自定义 scheme，用于从浏览器/其他应用唤起客户端）。它走的是另一套入口（open-url / 命令行参数解析），与上面那段不是同一个 handler。⇒ 你的现象很可能在这里，修法也在那里；
• dsh-app://...：客户端内部的页面/接口转发（上面那段）。

请补一句你实际点击/调用的链接原文（dsh:// 还是 dsh-app://，带完整 query）。这一个信息决定维护者该看哪一段代码——现在这两条路径混在一起，报告无法被定位。

3. 建议补的三样

1. 链接原文（含 query，敏感值可打码）；
2. 期望行为：query 里的哪个参数应当被传给谁（打开某个会话？定位某个文件？）；
3. dsh --version（你说 0.1.7-rc.2，请确认）。

4. 一个可立刻自证的方法

如果该深链是从网页触发的，请在 DevTools 里看实际发起的那次导航 URL（是否 query 在到达客户端之前就已经丢了）。"在客户端丢的"和"在触发侧就没带上"是完全不同的问题——这一步能把范围砍一半。

5. 版本

你在 0.1.7-rc.2 —— 就是当前最新（tag dsh-v0.1.7-rc.2），无需先升级。⚠️ 只是别把核换成 npm 的 latest（仍停在 0.1.5-rc.3，更旧）。

一条边界

我确认的是内部 dsh-app:// 转发会带上 source.search（所以那条路径不是问题所在）。dsh://open 那条深链我这边没有核到——这也是我请你先确认 scheme 的原因：在没确认之前，任何"应该改哪一行"的说法都是猜的。

[JoeSio]

感谢把 dsh-app:// 和 dsh:// 两条路径区分开，这个边界很清楚。

我不是楼主。我维护的是另一个社区插件（dsh-notify）：在回合完成 / 出错 / ask_user_question / approval/request 时发系统通知（Windows 走 snoretoast）。和本帖同一缺口：通知点击后无法直达触发通知的那条会话。

实际用的 scheme

是外部自定义协议，不是内部文档转发：

• 使用：dsh://open?session=<sessionId>（或等价形式）
• 不使用：dsh-app://…（与本需求无关）

插件在 Toast 点击后希望唤起的示例：

dsh://open?session=01JABCDEFG…

（sessionId 即根 agent id；宿主侧保证 agent.id === agent.session.id。）

期望行为

1. 聚焦 / 唤起 Desktop 主窗口（与现有 dsh://open 相同）。
2. 把 session 传到网页端。
3. 网页端调用 uiWorkspace.openSession(sessionId)，切到发出通知的那条会话。

现状只能唤回窗口，用户仍需自己在侧栏找会话。

源码核对（本地 harness 0.2.1-alpha.2 / tag dsh-v0.2.1-alpha.2，commit d743267388）

与楼主描述的缺口一致：

位置	现状
apps/desktop/src/main.ts（open-url）	仅精确匹配 dsh://open / dsh://open/ → focusPrimaryWindow()，不解析 query
apps/desktop/src/single-instance.ts	second-instance 只 focus，不读 argv
preload / DESKTOP_IPC	没有 open-session 通道到 renderer
Client	uiWorkspace.openSession(SessionTarget) 已存在

在 Windows 上，协议激活通常走 second-instance 的 argv，而不是 open-url（偏 macOS）。因此只改 open-url 不够覆盖「Toast → dsh://…」。

建议的最小 harness 改动（即可解封社区通知插件）

1. 解析 dsh://open?session=<id>（并覆盖 Windows 冷启动 / second-instance argv）。
2. 聚焦主窗口（复用现有逻辑）。
3. 投递到 renderer（建议 pending 槽 + push，避免冷启动 / 页面未就绪丢事件）。
4. 消费：client 侧 uiWorkspace.openSession(id)（同 id 幂等，双通道重复送达无害）。

更通用的「host 插件发通知并跳转」扩展点可以后做；仅深链透传 session= 就够社区通知插件接上。

官方出 nightly / PR 后，我可以从插件侧立刻实测并回反馈。