[Bug] Microsoft Store 版 PowerShell 7 无法出现在终端 shell 菜单（App Execution Alias 的 stat() 抛 EACCES）

[daujyungx]

Microsoft Store 版 PowerShell 7 无法出现在终端 shell 菜单（App Execution Alias 的 stat() 抛 EACCES）

环境

项	值
DSH	Desktop 0.2.1-rc.5（nightly 通道）
系统	Windows 11 25H2，build 26200（10.0.26200.0），x64
涉及 shell	PowerShell 7.6.9，Microsoft Store（MSIX）安装
别名	%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe（85 字节的 App Execution Alias）
真实可执行文件	C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.9.0_x64__8wekyb3d8bbwe\pwsh.exe
运行时	Electron 44.7.0 / Node 24.21.0

概要

右侧栏终端的 shell 菜单只列出探测通过的 shell——通常是 cmd.exe 与 powershell.exe——始终没有 pwsh.exe。而 pwsh 在 PATH 上，cmd 与 PowerShell 都能解析到，从资源管理器或通过 DSH 自己的 shell 工具直接启动也正常。

shellCandidates 默认值已经是 ["zsh", "bash", "fish", "pwsh", "powershell", "cmd"]，也就是说只要装了 pwsh 就应当在菜单中出现；实际失败是静默的，界面上没有任何错误提示。

复现步骤

1. 从 Microsoft Store 安装 PowerShell 7（或让它仅以 MSIX 形式存在）。
2. 确认系统可见：where pwsh → %LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe；pwsh -NoLogo -Command '$PSVersionTable.PSVersion' → 7.6.9。
3. 展开右侧栏 → 终端 → 标题旁的 shell 下拉菜单（或“新标签页”开始页）。
4. 列表只包含解析成功的 shell——通常是 cmd.exe 和 powershell.exe（若系统中存在 WSL 的 bash.exe 存根也会出现）。pwsh.exe 缺失。

预期：pwsh.exe 出现在列表中，可选中，并可作为新终端记住的 shell。
实际：pwsh.exe 始终不出现，也没有任何错误提示。

根因

两个包对“Windows App Execution Alias 算不算可执行文件”的判断不一致。

1. @deepseek-ai/dsh-subprocess-local 的 resolveExecutable() 用 fs.stat() 校验候选，并把任何异常都当作“继续找下一个”：

   for (const candidate of candidates) {
     try {
       if (!(await stat(candidate)).isFile()) continue;
       await access(candidate, constants.X_OK);
       return candidate;
     } catch {}
   }
   throw new SubprocessExecutableNotFoundError(...);

   在 Windows 上，%LOCALAPPDATA%\Microsoft\WindowsApps 下的 App Execution Alias 是一个重解析点：lstat() 显示为符号链接，stat() 会跟随进入 C:\Program Files\WindowsApps\... 并抛出 EACCES。catch 吞掉该错误，循环耗尽后，调用方收到的是“未找到”。

2. @deepseek-ai/dsh-api-terminal-controller 的 discoverShells() 只把 SubprocessExecutableNotFoundError 当作“未安装”跳过，其他异常继续上抛：

   try {
     return await resolveShell(subprocess, profile(candidate), signal);
   } catch (error) {
     if (error?.name === "SubprocessExecutableNotFoundError") return undefined;
     throw error;
   }

   于是 pwsh 候选从菜单中静默消失。

值得注意的是，DSH 自己的可执行文件查找实现（which 工具中的 isExecutable()）已经明确记录并处理了这一 Windows 行为：

// Windows App Execution Aliases (in `WindowsApps`) throw `EACCES` on `stat`,
// but are valid, launchable executables.
return isWindows && error.code === 'EACCES';

终端这条链路没有复用该判定，因此 Store 安装的 shell 对选择器不可见。

最小复现（纯 Node，无需 DSH）

const fs = require("node:fs");
const path = require("node:path");

const alias = path.join(process.env.LOCALAPPDATA, "Microsoft", "WindowsApps", "pwsh.exe");

console.log(fs.lstatSync(alias).isSymbolicLink()); // true
const target = fs.readlinkSync(alias);            // C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.9.0_x64__8wekyb3d8bbwe\pwsh.exe
fs.statSync(alias);                               // 抛出 EACCES: permission denied
fs.statSync(target);                              // 正常，isFile() === true

目标文件本身可 stat、可执行，只有沿别名跟随失败。

影响面

• 所有通过 Store 安装 PowerShell 7 的用户（Windows 上很常见的安装方式）都无法在 DSH 中选择 pwsh，尽管 DSH 默认就把 pwsh 列为候选。
• 同类由 MSIX 提供的 shell 一并受影响：其他 WindowsApps 别名（如 winget.exe、python.exe、notepad.exe）同样返回 EACCES。
• 失败是静默的，容易被误判为“配置问题”而不是“探测缺陷”。

临时规避（当前可用）

在 profile 补丁中补上解析后的真实路径。注意 config 是整体替换、不会深合并，因此需要完整重写候选列表：

- id: terminal-controller
  name: "@deepseek-ai/dsh-api-terminal-controller"
  config:
    shellCandidates:
      - zsh
      - bash
      - fish
      - pwsh
      - 'C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.9.0_x64__8wekyb3d8bbwe\pwsh.exe'
      - powershell
      - cmd

验证结果：加入该条目后 pwsh 可被发现（绝对路径能通过 stat()/access()），并以 PowerShell 7.6.9 启动。缺点是 Store 包升级会改变带版本号的目录名，该写法需要持续维护。

建议修复

1. 主要方案：在 subprocess-local.resolveExecutable() 中与 which 工具保持一致——win32 上把 stat() 返回的 EACCES 视为“存在且可执行”并返回该候选（同时跳过 access(X_OK)，它在 Windows 上无法区分是否可执行）。可将特例限定为 .exe 候选或 %LOCALAPPDATA%\Microsoft\WindowsApps 下的路径，把影响范围控制住。
2. 备选方案：让 discoverShells() 通过共享的 whichCommand() 解析候选，而不是维护第二套更弱的实现。
3. 测试：增加一个 Windows 专用回归测试，用 stub 模拟别名形态（lstat 返回符号链接、stat 抛 EACCES），即可同时覆盖解析器与发现流程，无需在 CI 中安装 MSIX。

补充验证

• 解析出的可执行文件可以正常启动：pwsh -NoLogo -NoProfile -Command "$PSVersionTable.PSVersion" → 7.6.9（直接使用包内路径）。
• 对测试过的所有 WindowsApps 别名都能复现相同的 stat 行为，说明这是 MSIX / App Execution Alias 的通用行为，而非 PowerShell 包自身的问题。

[aturzone]

Confirmed on current master fcc0ad4621, and implemented the narrow fix in the resolver that actually loses the shell.

Root cause matches the report. packages/subprocess/subprocess-local/src/index.ts probes each candidate with stat() + access(X_OK) inside a bare catch, so an App Execution Alias (stat() follows the reparse point into the target ACL → EACCES) is indistinguishable from "not installed"; resolveExecutable() then throws SubprocessExecutableNotFoundError, and discoverShells() correctly treats that as the shell being absent. The same package's pwsh-local/src/resolve.ts already documents the reparse-point behavior (candidateExists() uses lstat() for exactly this reason), but the terminal path never reaches that resolver.

Patch — branch: https://github.com/aturzone/deepseek-harness/tree/fix/windows-alias-executable, commit 367504a9a7:

• on Windows, a stat() failure with EACCES or EPERM and an lstat() entry that is a file or symlink is accepted as a launchable alias (current Node reports the alias as a symlink; older releases as a plain file);
• every other failure keeps the existing next-candidate / stable not-found behavior, and non-Windows platforms are unchanged;
• the helper takes the platform explicitly so the Windows decision is testable here.

Evidence. New spec injects a stat() EACCES and stubs process.platform = 'win32', then resolves a real symlink entry: the alias is returned (without the catch handling the same test fails). Negative cases cover off-Windows, ENOENT, and a missing entry. packages/subprocess/subprocess-local/tests: 379 passed; two failures in that run (spawn-runner.spec.ts Windows-path expectation, shell-activity.spec.ts bash PS0 timing) reproduce identically with my source change stashed, so they are pre-existing in this environment. pnpm run typecheck is 5/5 gates; Oxlint has 0 errors.

Design note: I kept the helper local to subprocess-local rather than importing pwsh-local (the shell providers depend on subprocess, not the reverse). If the team prefers one shared "Windows alias entry" predicate, the natural home is a util package both can import; happy to move it.

[aturzone]

While verifying this patch on the current checkout, I found and fixed a test-isolation defect in the same package (second commit 8fc89ac081 on the same branch).

spawn-runner.spec.ts's Windows executable-resolution cases relied on the ambient NoDefaultCurrentDirectoryInExePath value through the resolver's default currentEnv. Hardened hosts (this verification machine exports it) remove the default cwd search, so the documented target-cwd expectation failed with expected ['C:\target\relative\bash.com', …] to deeply equal ['C:\target\bash.com', …] while the implementation was correct. The six calls that exercise the default policy now pass an explicit empty currentEnv; the two dedicated policy tests keep their explicit environment. The suite passes on hosts with and without the variable.

This is test-only and not part of the shell-menu defect; it is included because it was blocking clean verification of the resolver change.

[enhenglove69]

补充一条来自另一套 MSIX 包的数据，顺便确认最新代码里仍未修复：

环境

• DSH Desktop 0.2.2-rc.1（nightly 通道）；app.asar 内 dsh / dsh-subprocess-local / dsh-pwsh-local / dsh-api-terminal-controller 均为 0.2.2-rc.1
• Windows 11 24H2（10.0.26100.9818），x64
• Microsoft.PowerShellPreview 7.7.101.0（内部版本 7.7.0-rc.1），Store/MSIX 安装

别名行为（%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe，IO_REPARSE_TAG_APPEXECLINK 0x8000001B）

• lstat → symlink（size 94）
• stat → EACCES
• .NET File.Open → IOException HResult 0x80070780（ERROR_CANT_ACCESS_FILE = 1920）
• readFileSync → EACCES

现象

• 右侧栏终端 shell 菜单只有 cmd.exe / bash.exe / powershell.exe，没有 pwsh.exe；但 pwsh 在 PATH 上可正常执行（DSH 自己的 pwsh 工具能识别，因为 dsh-pwsh-local 用的是 lstat 判定）。
• 用 shellCandidates 填真实包路径后菜单恢复正常，可启动 7.7.0-rc.1；缺点是 Store 升级会改变带版本号的目录，需要持续维护。

代码现状（已核对）

• master 最新提交 fcc0ad4（v0.2.2-rc.1，2026-11-04）里，packages/subprocess/subprocess-local/src/index.ts 的 resolveExecutable() 仍是 stat() + access(X_OK)，没有 lstat/EACCES 感知；
• 该文件最近一次修改是 2026-10-14 的 Linux containment 重构，之后没有针对 Windows 别名的改动；
• 所以修复分支（aturzone 的 fix/windows-alias-executable）尚未合入 master。

TL;DR: Same stat()/EACCES behavior reproduces with Microsoft.PowerShellPreview 7.7 (MSIX). Latest master fcc0ad4 / v0.2.2-rc.1 still uses stat() + access() in subprocess-local.resolveExecutable; the lstat fix is not merged yet. +1 for landing it (also fixes #11975).