[Bug] native-command: openNativeFileApplication always fails for directories (Path.GetExtension early-return)

[explorerxx]

环境：@deepseek-ai/dsh-native-command 0.1.7-rc.2 与 0.2.0-rc.2（行为一致），Windows 11 26H2（build 26300）

file-applications-windows.js 的 Visit() 在路径没有扩展名时直接返回，于是传目录进来时一个 handler 都不枚举：

var extension = Path.GetExtension(path);
if (extension.Length == 0) return;      // ← 目录在这里被静默丢弃

最小复现（对照组只差一个扩展名）：

输入	nativeFileApplications	openNativeFileApplication
C:\Users\me\some-folder（目录）	0 项	抛 Application is not registered for this file
%TEMP%\probe.md（同内容、带扩展名）	6 项	成功打开

期望：目录按其 Directory 关联打开，或回退到 shell 的 open verb。
实际：静默返回 0 项 / 抛异常。
影响：接口层缺陷 —— 目前未在 UI 上确认稳定的目录触发路径，属健壮性问题：任何把目录交给该接口的调用方都会失败。它与另一个 catalog 缺陷撞在同一句用户提示「打开失败，请重试」上，排查时容易互相误判。
建议修法：见下方补充评论 —— 原先写的"去掉早退"不成立（extension 是喂给 SHAssocEnumHandlers 的入参），需要单独分支或明确拒绝。
去重说明：已用 8 组关键词（openNativeFileApplication、nativeFileApplications、Path.GetExtension、file-applications-windows、Application is not registered、directory open in app、目录 打开失败、文件夹 打开方式）检索全部 Discussions，无同题；最近的 4 条（#7860 / #7021 / #9455 / #9697）症状相近但根因不同，区别见下方折叠区。

展开：复现脚本与去重证据

复现脚本（Node，直接调用运行时真实加载的入口）：

const { createRequire } = require('node:module');
const req = createRequire('<dsh 安装目录>/node_modules/@deepseek-ai/dsh-api-session-controller/');
const mod = await import(req.resolve('@deepseek-ai/dsh-native-command'));
await mod.nativeFileApplications('C:\\Users\\me\\some-folder', new AbortController().signal, { run }); // → []

检索记录（2026-10-15，8 组关键词）：

关键词	命中	结论
openNativeFileApplication	2	#9053（VS Code Remote-WSL 窗口复用）、#7842（windowsHide 隐藏 Explorer）—— 均非同一问题
nativeFileApplications	5	全是坏 handler 家族（#7874/#8839/#8715/#7757/#8019）
Path.GetExtension	1	#8049（环境变量泄漏帖，正文顺带提及）
Application is not registered	75	全是无关话题（短语过于通用）
file-applications-windows	32	坏 handler + windowsHide 系列，无一涉及"目录 / 无扩展名"
directory open in app	246	泛化命中；仅 #7860 值得点名
目录 打开失败	59	全是环境变量泄漏家族（#8304/#8668/#8483/#9254/#8428/#8958/#8652/#8582/#9689）
文件夹 打开方式	12	#7099 / #9455 / #9697 / #7021，根因各不相同

结论：Visit() 因缺少扩展名而早退这一条，没有同题。

必须点名的 4 条"症状相近、根因不同"（避免被当成重复）：

相近帖	它的根因	与 ② 的区别
#7860 "Open folder" spawns explorer.exe but does not open the directory	explorer 委派 / windowsHide	是"拉起了却没显示"，不是"枚举不到应用"
#7021 windowsHide 用在 GUI 程序上…并导致整个目录后续无法打开	windowsHide	同上，前提不同
#9455 「显示文件位置」不打开文件夹…explorer.exe 等待没有超时	explorer 等待无超时	另一条链路（reveal），与应用枚举无关
#9697 openWorkspacePath 一律拒绝含 junction 或符号链接的路径	路径校验规则	是显式拒绝，不是静默 0 项 / 抛异常

[PerryLink]

你找的位置完全准确，逐字对上了。packages/util/native-command/src/file-applications-windows.ts:181-185：

static void Visit(string path, Action<IHandler> visit) {
  var extension = Path.GetExtension(path);
  if (extension.Length == 0) return;
  IEnumHandlers handlers;
  SHAssocEnumHandlers(extension, 0, out handlers);

不过我要补一点，它会影响你提的修法：Path.GetExtension 在这里不只是个守卫，它就是喂给 Shell API 的入参。 也就是 :185 那句 SHAssocEnumHandlers(extension, ...) 收的是扩展名字符串本身，不是路径。所以"把早退去掉"并不能修好——去掉之后会把空字符串传给 SHAssocEnumHandlers，一样枚举不出来。

这意味着目录要能打开，得换成另一条 Shell 路径（比如走 Directory 关联，或者干脆回退到 open verb），而不是放宽这个判断。你在建议里提到的 openNativeAssociatedPath 回退方向是对的，但它不是"顺带就能用上"的——需要单独实现一条目录分支。

你大概没注意到的第二处

同一个文件里，:196-199 的 List() 用的是同一个判断，而且它管的不只是 handler 列表：

public static Application[] List(string path) {
  var extension = Path.GetExtension(path);
  var executable = extension.Length == 0 ? null : Associated(extension, 2);
  var appId = extension.Length == 0 ? null : Associated(extension, 21);

:198 和 :199 分别是默认程序的 exe 和默认程序的 appId——目录进来时两者都是 null。

所以"目录下 0 项"不只是 handler 枚举不到，连"这个类型默认用什么打开"也没有。这解释了为什么症状是"0 项"而不是"有项但打开失败"：整条链从默认程序那一步就是空的。这一点建议写进报告，它比只说 Visit 更完整。

至于那个异常

你观察到 openNativeFileApplication 抛 Application is not registered for this file。我要说明一下：file-applications.ts:181 那句抛错是在非 Windows 分支里的（:180 先查列表、:181 再校验）。Windows 分支在 :176-178 直接走 windowsFileApplications，它的校验在 file-applications-windows.ts:247 那个函数里。

我这边没有逐行确认 Windows 分支抛的是不是同一句文案——你既然实测到了，就以你的为准，只是引用位置时建议指到 file-applications-windows.ts 这边，别指到 file-applications.ts:181，否则维护者会发现平台对不上。

版本情况

我查了这个文件从 dsh-v0.2.1-alpha.2 到 dsh-v0.2.1-alpha.3 的 diff：一个字都没改。file-applications.ts 和 path-opener.ts 同样未改。所以你说的"0.1.7-rc.2 与 0.2.0-rc.2 行为一致"在最新线上仍然成立——这条缺陷今天还在，而且 0.2.1-alpha.3（2026-10-14 发布）里也没有修复。

一个措辞建议

你把影响面定位成"接口层健壮性问题、目前未在 UI 上确认稳定触发路径"——这个自我限定很稳，建议保留。

不过可以再具体一点：openNativeFileApplication 的文档注释（file-applications.ts:162-170）写的是 "Open a file in a currently registered handler"，参数说明也是 "verified absolute local file path"。也就是说这个接口的契约本来就是"文件"，目录不在它的承诺范围内。所以更准确的定性是"契约与实现都没覆盖目录，而调用方可能传目录进来"——这比"实现有 bug"更贴近实际，也更容易让维护者决定是补目录支持还是加拒绝校验。

你要不要主张"支持目录"取决于是否有真实调用方需要；如果只是健壮性，那"传目录时给出明确错误"可能比"支持目录"更容易被接受。两条我建议你都写出来，让维护者选。

那目录到底该走哪条路

如果你确实想让"用某个应用打开目录"这件事成立，方向不在这个文件里。仓库里已经有目录的路径了：packages/util/native-command/src/path-opener.ts:154 的 openWindowsPath，最后落到 :188 的 explorer.exe（runExplorer 在 :136）；另外 :274 的 nativeFileManager() 就是专门回答"这个平台的目录管理器是什么"的。目录归 openNativePath 那一面，不归 file-associations 这一面。

所以更实际的建议是改调用方准入，而不是改 Visit()：packages/api/session-controller/src/index.ts:375 那句 else if (request.application !== undefined) await this.openFileApplication(path, request.application, signal) 之前，按 fs.stat().isDirectory() 分流一次，目录就忽略 request.application 走 this.openPath。我核过 :412 的 verifyDesktopPath 只做路径租户校验、不判是否目录，所以目录确实能走到这里来——这条准入缺口是实打实的。

你担心的"互相误判"，机制我找到了

你这句判断很准，而且有具体出处。现在"打不开"至少有两条路径会显示同一句提示：

• 抛错（你现在这条）；
• 什么都没发生但报成功：path-opener.ts:143 那句 if (!(error instanceof Error) || !('code' in error) || error.code !== 1) throw error 把 explorer 的退出码 1 一律当成功，而 README.md:112 自己承认在非交互会话里「explorer.exe 什么都不打开、约一秒后仍以 1 退出，于是 open 报成功却什么都没打开……该会话下的兜底尚未实现」。

两者最后都落到 packages/client/ui-open-in-app/src/client/locales.ts:51 的 'path.openError': '打开失败，请重试'，确实分不出来。这条值得单独提一句。

顺带一个附带发现：packages/util/native-command/src/runner.ts:27-30 的 execFile options 里仍然只有 encoding / signal / windowsHide，没有 timeout——explorer 挂住时只能靠调用方的 signal 兜底。这个和你这条不是同一个问题，但同一个包，你可以一并提。

边界

我核的是 origin/master = 571902028a（2026-10-14）。这个文件从 dsh-v0.2.1-alpha.2 到 dsh-v0.2.1-alpha.3 的 diff 是空的（path-opener.ts、file-applications.ts、file-applications-windows.ts 三个都未改），所以上面这些结论在 0.2.1-alpha.3 上同样成立。

你是 Windows 11 build 26300，实测断言我没法在这边复现；上面说的都是源码层面的事实。另外你那个去重说明（8 组关键词、与 #7860 / #7021 / #9455 / #9697 的区别）做得很细，省了维护者一轮比对。

[explorerxx]

补一条自我更正与几点实测扩展。

感谢 @PerryLink 的源码级复核（对照 origin/master = 571902028a，2026-10-14）——
其中"去掉早退并不能修好"这一条推翻了我首楼里的建议，先更正，再补实测与两处他人未覆盖的点。

0）更正：我原先写的"去掉 Visit() 里的早退"不成立

Path.GetExtension(path) 的结果不只是守卫，它就是喂给 Shell 的入参 ——
SHAssocEnumHandlers(extension, …) 收的是扩展名字符串而不是路径。
去掉早退只会把空串传进去，一样枚举不出来。正确方向是单独一条分支（见第 2 点），不是放宽判断。

1）范围比我原先写的大：没有扩展名的普通文件同样打不开，而这落在接口契约之内

实测（@deepseek-ai/dsh-native-command 0.2.0-rc.2 原始实现，与桌面端 app.asar 逐字节一致；
Windows 11 26H2 / build 26300）：

输入	nativeFileApplications	openNativeFileApplication(…, Code.exe)
%TEMP%\dsh-probe-noext（无后缀文件）	0 项（469 ms）	抛错 Application is not registered for this file
%TEMP%\dsh-probe-withmd.md（对照）	6 项（WPS Office / Typora / VS Code / 记事本 / …）	成功
%TEMP%\.dsh-probe-dotfile（点开头）	6 项（记事本 / VS Code / WPS表格 / …）	——

第三行是关键：点开头文件之所以可用，是因为 .NET 的 Path.GetExtension(".dsh-probe-dotfile")
返回非空字符串，Shell 便回退到"未知类型 / 默认"那一组 handler。也就是说
同一 API 只要拿到非空关联串就能给出结果 —— 无扩展名这条缺的正是这个串。

2）因此修法建议改为两条，请维护者择一

• A. 支持：为"无扩展名路径"补一条分支，用 Shell 的未知类型关联（或以路径初始化
  IQueryAssociations）取默认集合；目录再单独走 Directory 关联；
• B. 明确拒绝：该接口文档写的是 "Open a file in a currently registered handler"、
  参数是 "verified absolute local file path" —— 目录本不在承诺范围内。那么在入口把目录
  （及无扩展名路径）分流，给出明确错误，而不是"空列表 + 泛化抛错"。

（B 的连带好处：把目录从这条链路上彻底挡掉，不会与 openNativePath 那侧的目录能力混淆。）

3）调用方准入缺口（比改 Visit() 更实际）

packages/api/session-controller/src/index.ts:375 的
else if (request.application !== undefined) await this.openFileApplication(path, request.application, signal)
之前没有按类型分流，而 :412 的 verifyDesktopPath 只做路径租户校验、不判是否目录，
所以目录确实能走到这里。建议在调用方按 fs.stat().isDirectory() 分流：目录忽略 request.application、
走 this.openPath —— 目录能力本来就在 path-opener.ts 的 openWindowsPath / nativeFileManager() 那一侧。

4）异常文案的出处（更正引用位置）

实测抓到的原始报错来自 Windows 侧生成的 PowerShell 适配脚本，而非跨平台分支：

Command failed: powershell.exe … -File …\dsh-native-command-<tmp>\associations.ps1
  | 使用"2"个参数调用"Open"时发生异常:"Application is not registered for this file"

引用请指向 file-applications-windows.ts（及其 associations.ps1 模板），不要指向
file-applications.ts:181，否则维护者会发现平台对不上。

5）List() 里的第二处（比只提 Visit() 更完整）

file-applications-windows.ts:196-199 用同一个判断决定默认程序：

var executable = extension.Length == 0 ? null : Associated(extension, 2);
var appId      = extension.Length == 0 ? null : Associated(extension, 21);

于是目录/无扩展名路径连"这个类型默认用什么打开"都是 null —— 这解释了症状为何是
"0 项"而不是"有项但打开失败"：整条链从默认程序那一步就是空的。

6）两条附注（同包，另案）

• 同一句提示掩盖两种失败：path-opener.ts:143 把 explorer 的退出码 1 一律当成功，
  而包内 README.md:112 自承"非交互会话下 explorer 什么都不打开、约 1 秒后仍以 1 退出，
  open 报成功却什么都没打开……该会话下的兜底尚未实现"；与本条（抛错）最终都落到
  locales.ts:51 的同一句「打开失败，请重试」，确实分不出来 → 建议给出可区分的诊断。
• runner.ts:27-30 的 execFile 选项里没有 timeout（只有 encoding / signal / windowsHide），
  explorer 挂住时只能靠调用方 signal 兜底。

7）版本状态：file-applications-windows.ts / file-applications.ts / path-opener.ts
在 dsh-v0.2.1-alpha.2 → dsh-v0.2.1-alpha.3（2026-10-14）之间一行未改，本缺陷在最新版仍未修。