DeepSeek Harness 桌面端壳集成：打开与显示失败、打包技能缺失、stderr 不可见与宿主启动失败
DeepSeek Harness（DSH）桌面端有一整类问题不是「功能坏了」，而是它和系统壳层之间的约定没对上**：打开方式列表因为一个坏的注册项整体为空、对目录永远打不开、工作区里经过链接的路径被判定为「没有有效宿主路径」、映射盘符被规范化成 UNC；打包形态下系统提示指向归档内部路径、cordis 预设的官方技能整块缺失（而且桌面端没有可见控制台，所以完全静默）；通知点击回不到对话（自定义协议少了 ServiceWorker 特权）、插件运行期报错看不到（宿主只转发标准输出、不转发标准错误）；以及在第三方 Electron 宿主里全量启动失败。** 这一族的共同排查心法是：先把「用哪种形态运行」固定下来——源码运行正常、打包复现，或 web 正常、桌面复现，基本就能定位到下面哪一段（#8839、#9774、#9697、#9223、#9216、#9756、#9608、#8800、#9543、#9017）。
DeepSeek Harness 打开与显示：三个入口一起失效
DSH插件 打开方式列表为空：一个坏处理器拖垮整批
一句话结论：枚举系统打开方式的循环里逐个读取应用名称时没有单项容错**，系统里只要残留一个坏注册项，整份列表就整体失败——连默认打开也会受影响。** 报错形态是文件应用查询失败（#8839）。
- 判据：你打开菜单会看到「无法加载应用」、程序列表为空；换一批文件仍然空（#8839）。
- 常见诱因：卸载某个编辑器后留下的注册表残留项（讨论中举的例子是卸载写字板后的残留项）（#8839）。
- 临时处置：清理残留注册表项，或改用系统默认方式打开文件（#8839）。
- 修法：把 try/catch 放在单项读取这一层（跳过坏项并记录日志），而不是包住整个循环——否则会从一个坏项退化成整批不可用（#8839）。
DeepSeek Harness 目录打不开：扩展名为空时提前返回
一句话结论：取扩展名时会提前返回**，而这个扩展名正是喂给系统枚举接口的入参——所以目录既拿不到候选应用、默认应用也是空。** 症状是「用某应用打开」对目录（或任何无扩展名路径）一律失败，而对带扩展名的文件正常（#9774）。
- 判据：同一功能对文件可用、对目录不可用（#9774）。
- 重要前提：该接口文档本身只承诺处理「文件」，所以更合理的修复落点在调用方准入——先判断目标是不是目录，给出明确错误，而不是放宽枚举逻辑（#9774）。
- 处置：你可以改用「在文件管理器中显示」（它走的是另一条链路，不受本条影响）；或先把目录里要打开的文件指定出来（#9774）。
DeepSeek Harness 工作区里经链接的路径被拒
一句话结论：校验把「按字面解析后的路径」与「解析真实路径后的目标标识」直接比较——链接路径永远不可能相等，于是被判为「无有效宿主路径」。 症状是「打开方式 / 用默认应用打开 / 在文件管理器显示 / 列出可用应用」四个入口一起失败（#9697）。
- 判据：同一条路径避开链接（用真实路径）就正常；四个功能同时失效是本条特征（#9697）。
- 处置（用户侧）：你可以直接用真实路径打开目标（#9697）。
- 修法：比较前先对链接做一次真实路径归一；并补测试——讨论指出这块零测试覆盖，所以四个入口一起坏也没人发现（#9697）。
DeepSeek Harness 映射盘符被改写成 UNC
一句话结论：路径规范化直接调用系统的真实路径解析；Windows 上它会把映射盘符解析成网络路径，于是展示与持久化都变成 UNC（主机名一并暴露），而同一目录用盘符访问还会被判成在工作区之外。（#9223）
- 判据：加工作区后标题与工具路径显示为
\\server\share\...形态；用原盘符访问同一目录时报「不在工作区内」（#9223）。 - 处置：你可以把工作区改到本地盘，或接受 UNC 展示但注意脚本里的盘符引用需要同步调整（#9223）。
- 修法：分存「用户拼写」与「内部规范身份」——展示与持久化保留盘符拼写，唯一性判断仍用规范身份，这样同一目录不会出现两条工作区记录（#9223）。
DeepSeek Harness 打包（asar）路径：提示不可达、技能整块缺失
一句话结论：三类问题同源——某些路径在打包后被解析到归档（asar）内部，而归档内部路径不可被普通文件工具读取、也不可被目录监听**；同时桌面端没有可见控制台，所以失败表现为静默。**（#9216、#9756、#9608）
| 现象 | 机制 | 处置 |
|---|---|---|
| 系统提示里的 implementation checkout 指向归档内部，agent 工具读不到、首轮反复失败 | 该路径由「相对当前模块定位仓库根」的方式推导，打包后落在归档内部（#9216） | 关掉该提示段（配置里把相关开关设为关闭），注意补丁是整行替换，要复述其它键（#9216） |
| cordis 预设下官方技能整块缺失、无报错 | 预设用表达式把技能目录指到归档内部；该目录不带受信任宿主标记，于是走了读不了归档的通道，读取失败被跳过（#9756） | 在 profile 补丁里把技能目录改写为真实磁盘路径；上游修法是改用带受信任标记的打包技能目录配置（注意其排序权重会变）（#9756） |
cordis 模式下 <available_skills> 目录从不注入（模型不知道有技能） | 归档内部目录 stat 能成功，但目录监听失败，导致整份观察结果被标为不完整，技能工具按「不完整就丢弃」处理（#9608） | 同上；要点是「单个根监听失败拖垮整个提供者」+ 可观测性缺失（#9608） |
统一处置步骤：
DeepSeek Harness 壳层能力：通知点不回去、插件报错看不到
DeepSeek Harness 通知点击回不到对话：自定义协议少了 ServiceWorker 特权
一句话结论：自定义协议在声明特权时没有声明支持 ServiceWorker**，于是该协议源下注册服务工作线程被拒绝——通知类插件的「点击跳回对话」「审批快捷裁决」等能力整体失效。** 判据是控制台里出现「当前源的协议不受支持」一类提示（#8800）。
- 判据：通知能弹出、点击无反应；控制台有明确的协议不支持提示（#8800）。
- 处置（用户侧）：你可以换用插件提供的替代入口（例如自建深链抬窗）（#8800）。
- 修法：在应用就绪前声明该协议支持 ServiceWorker（一行级改动）（#8800）。
DSH插件 运行期报错完全看不到：只转发标准输出
一句话结论：宿主只把子进程的标准输出转发出来，标准错误只写进一个固定大小的内存环形缓冲、退出时才可能被读到——插件用控制台写错误时正好走标准错误，所以运行了很久的失败也没留下任何日志。（#9543）
- 判据：插件行为异常但日志目录干净；讨论中举的例子是一个定时任务失败了数小时、唯一信号从未进日志（#9543）。
- 插件侧规避（当前最有效）：改用日志服务并注册自己的输出端，把消息写到自有文件；注意这看不到直接写标准错误的第三方插件（#9543）。
- 修法：宿主也转发标准错误（讨论指出凭据顾虑不成立——标准输出本身已无过滤转发，且可加开关）（#9543）。
DeepSeek Harness 第三方 Electron 宿主：全量启动失败
一句话结论：某个原生模块自某版本起内置了 Electron 运行时指纹校验，而白名单是补丁级精确的引擎指纹**（报错文案却只写大版本，误导性很强）；同时启动路径直接调用该模块、不检查必要的启动参数、也没有异常兜底——所以即使补上参数仍然会致命失败。** 报错形态是宿主准备失败、提示运行时不支持（#9017）。 若启动失败发生在官方桌面端、并表现为「只剩托盘或干脆没有窗口」，则属桌面端启动一族，可对照 DeepSeek Harness 桌面端启动异常：没有窗口、启动崩溃、EMFILE 与 80 秒单核满载。
- 判据：把第三方 Electron 二进制当 node 用时，任何 profile 启动即失败；换纯 node 或官方运行时正常（#9017）。
- 处置：不要在第三方 Electron 宿主里派生 DSH——改用纯 node 启动，或用官方运行时（#9017）。
- 互引：这条与「桌面端把
ELECTRON_RUN_AS_NODE透传给子进程导致 Electron 应用退化成 node」是同一环境变量的内/外两个方向，排查时一起看（#9017）。
DSH插件 排查注意事项
这一族的第一条纪律：先固定运行形态（源码 / web / 打包桌面 / 第三方宿主），再比对该形态下的差异。 九条要点：
- 「源码正常、打包复现」= 归档路径问题，别去查权限（#9756）。
- 「web 正常、桌面复现」= 壳层能力或宿主差异（#9543）。
- 静默失败先怀疑没有可见控制台，桌面端尤其如此（#9756）。
- 打开方式那两条都是「一处异常整批失效」，关键是找出单项而不是整体（#8839、#9774）。
- 四个入口一起坏 = 共用同一处判定（#9697）。
- 路径问题优先怀疑「规范化把用户拼写改掉了」（#9223）。
- 补丁层是整行替换：改归档相关配置时要复述其它键（#9216）。
- 技能缺失与提示路径不可达常同时出现，因为它们同源（#9216、#9756）。
- 修复状态如实：十条在讨论所指版本（
0.2.0-rc.2前后）里都未修；本文处置均为用户侧改写配置、换入口或换运行形态，官方未宣布修复。
桌面端的壳集成问题常常和「装了哪些插件、哪个插件在写标准错误」纠缠在一起。与其在各处手敲命令，不如用 DSH Plugin Hub 这类可视化插件市场：已安装列表、装卸历史与系统日志集中在一个面板里，先确认环境。
来源：Discussion #8839、Discussion #9774、Discussion #9697、Discussion #9223、Discussion #9216、Discussion #9756、Discussion #9608、Discussion #8800、Discussion #9543、Discussion #9017。
常见问题
DeepSeek Harness 打开方式列表整体为空，是因为枚举系统打开方式的循环逐个读取应用名称时没有做单项容错：系统里只要残留一个坏注册项（例如卸载某个编辑器后留下的注册表键），整份列表就整体失败。判据是换成另一批应用仍然空、且报错提到文件应用查询失败。临时办法是清理残留的注册表项或换用系统默认方式打开；修法是逐项捕获异常、跳过坏项并记录日志，而不是让整批失败。
DeepSeek Harness 对目录调用「用某应用打开」总是失败，是因为那条链路在取扩展名时对空扩展名提前返回，而这个扩展名正是喂给系统枚举接口的入参，所以目录连「有哪些候选应用」都拿不到、默认应用也是空。正确做法是在入口先判断目标是不是目录并给出明确错误，或补一个无扩展名分支；要注意接口文档本身就只承诺处理「文件」，所以更合理的是在调用方分流。
DeepSeek Harness 会把工作区里经 junction 或符号链接访问的文件判成无有效宿主路径，是因为校验拿「按字面解析后的路径」与「解析真实路径后的目标标识」直接比较，链接路径永远不可能相等。四个入口共用同一处判定且这块没有测试覆盖，所以四个功能一起失效。规避是直接用真实路径打开；根治要改成对链接做一次真实路径归一后再比较。
DeepSeek Harness 桌面打包版在 cordis 预设下技能一个都不显示，是因为该预设用表达式给技能文件系统配了自定义技能目录，而这个表达式在打包后解析到归档内部路径；这些目录不带受信任宿主标记，于是走了不能读归档的通道，读取失败后被跳过——桌面端又没有可见控制台，所以表现得完全静默。修法是改用带受信任标记的打包技能目录配置，或把配置改写成真实路径。
DeepSeek Harness 桌面端看不到插件的运行期报错，是因为宿主只转发了标准输出，标准错误只写进一个固定大小的内存环形缓冲、退出时才可能被读到。插件用控制台写错误时正好走的是标准错误，所以运行了五小时的失败也没有留下任何日志。应急做法是让插件改用日志服务并注册自己的输出端；根本方向是让宿主也转发标准错误，或在界面上提供查看入口。
相关术语
- 打开方式（open in app）
- 打开方式指桌面端把文件交给系统注册的某个应用打开的能力，实现上需要向系统枚举可用的处理器并取用其名称与标识。枚举过程中任一项异常若不被单项捕获，就会让整份列表失败。— https://github.com/deepseek-ai/deepseek-harness/discussions/8839
- asar 归档路径
- asar 是 Electron 应用打包时使用的归档格式，其中的路径在运行时表现为一个虚拟文件系统。它能被部分读取接口访问，但不能被目录监听等机制正常使用，因此把技能目录或检出目录指向归档内部会导致读取或监听失败。— https://github.com/deepseek-ai/deepseek-harness/discussions/9756
- trustedHost
- trustedHost 是 DeepSeek Harness 技能目录配置上的一个标记，表示该目录应通过原生文件系统通道（可直接读取归档）访问。自定义技能目录默认不带该标记，因此会被路由到另一个读取通道，进而在归档路径上失败。— https://github.com/deepseek-ai/deepseek-harness/discussions/9756
- 自定义协议特权（registerSchemesAsPrivileged）
- registerSchemesAsPrivileged 是 Electron 在应用就绪前声明自定义协议能力的接口，可声明标准、安全、支持 ServiceWorker 等特权。未声明 ServiceWorker 特权时，该协议源下注册服务工作线程会被拒绝。— https://github.com/deepseek-ai/deepseek-harness/discussions/8800
来源
- #8839 — "open in app" breaks due to one broken handler — windowsFileApplications fails on a stale COM handler· deepseek-ai（GitHub Discussions）
- #9774 — native-command: openNativeFileApplication always fails for directories· deepseek-ai（GitHub Discussions）
- #9697 — session 的 openWorkspacePath / workspacePathApplications 一律拒绝「路径中含 junction 或符号链接」的文件· deepseek-ai（GitHub Discussions）
- #9223 — Windows 工作区路径未保留映射盘符拼写· deepseek-ai（GitHub Discussions）
- #9216 — 桌面打包版：系统提示词宣传的 implementation checkout 指向 app.asar 内部虚拟路径· deepseek-ai（GitHub Discussions）
- #9756 — 桌面端 cordis 预设下官方技能不加载：!!js customSkillDirs 解析到 app.asar 内部· deepseek-ai（GitHub Discussions）
- #9608 — 桌面版 Creator（cordis）模式下 <available_skills> 目录从不注入· deepseek-ai（GitHub Discussions）
- #8800 — dsh-app:// 协议未注册 ServiceWorker 特权，通知类插件整体失效· deepseek-ai（GitHub Discussions）
- #9543 — Desktop: host stderr is never forwarded· deepseek-ai（GitHub Discussions）
- #9017 — 第三方 Electron 宿主（Electron-as-node）下 dsh 全量启动失败· deepseek-ai（GitHub Discussions）