[BUG]WSL下VS Code/Cursor图标显示异常

[changde-tuya]

Bug 报告：Linux 上 GET /open-in-app/icon/<id> 对已安装编辑器返回 404（vscode、cursor）

摘要

在 Linux（WSL2）上，Web 会话头部的 "Open In..." 分体按钮里，vscode 与 cursor 显示为通用占位方块而非应用真实图标。两个应用都已被正常探测到、也能正常启动——坏的只有图标。图标路由返回 404，响应体为 {"code":"not-found","message":"no icon for <id>"}。

目录路由本身是正常的：

GET /open-in-app/apps        -> 200 {"apps":["cursor","vscode"]}
GET /open-in-app/icon/vscode -> 404 {"code":"not-found","message":"no icon for vscode"}
GET /open-in-app/icon/cursor -> 404 {"code":"not-found","message":"no icon for cursor"}

期望：200 并返回应用真实图标（PNG 或 SVG），与包 README 的描述一致（"图标路由在每个可提取的平台上提供应用真实图标……Linux 上为 desktop 条目在 hicolor 主题中的图标（PNG 或 SVG）"）。

浏览器控制台：

:3080/open-in-app/icon/vscode:1  Failed to load resource: the server responded with a status of 404 (Not Found)
:3080/open-in-app/icon/cursor:1  Failed to load resource: the server responded with a status of 404 (Not Found)

环境

dsh	0.1.6-alpha.2（commit 4eec5ceb01）
操作系统	Linux（WSL2，内核 5.15.167.4-microsoft-standard-WSL2），以源码检出方式运行
上报平台	linux——因此走 Linux 图标策略；应用运行在 WSL 内，而非 Windows 宿主
浏览器	Edge / Chromium 内核
相关环境变量	DISPLAY=:0、WAYLAND_DISPLAY=wayland-0（WSLg 存在）、XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop、XDG_CURRENT_DESKTOP 未设置
图标主题包	一个都没装——本机 /usr/share/icons/hicolor/*/apps/ 为空

复现步骤

1. 在 Linux 侧以一种不安装图标主题包的方式安装 VS Code——例如解包的／便携式目录树，其启动器是 bin/code 垫片（Windows 版下载包的布局），使该条目经 cli locator 解析并出现在菜单中。确认本机不存在可用的 code.desktop 的 Icon= 目标，也不存在 hicolor/…/apps/code.png。
2. 打开 Web 界面，展开 "Open In..." 菜单。
3. 观察：条目已在列表中且可以启动，但显示通用占位图形；DevTools 中 /open-in-app/icon/vscode 返回 404。

同一台机器上的 cursor 属于卸载不彻底的情形：Cursor 以前装过，后来卸载了，但残留的 cursor 垫片仍能在 PATH 上解析到。于是条目依旧被提供，却既没有 desktop 条目也没有主题图形，图标路由返回 404。

根因（读源码所得）

两处失败都在图标提取的 Linux 分支 packages/host/open-in-app/src/icons.ts，且共享同一个假设：desktop 条目里写了图标名，就证明本机真有这张图。 但 freedesktop 的 desktop 条目只是声明了一个图标名，真正的像素通常属于另一个图标主题包——而那个包完全可能没装。

A. 主题查找写死了 hicolor 主题与固定尺寸表

findLinuxThemeIcon 只探测：

<dataDir>/icons/hicolor/{512x512,256x256,128x128,64x64,48x48,32x32}/apps/<name>.{png,svg}
<dataDir>/icons/hicolor/scalable/apps/<name>.svg
<dataDir>/pixmaps/<name>.{png,svg}

三个写死的假设，任意一条不成立即 404：

1. 主题永远是 hicolor。 用户的活动主题（XDG_CURRENT_DESKTOP、XDG_ICON_THEME）按 README「Known Limitations」是刻意不查的，因此只存在于活动主题中的图形完全看不见。
2. 尺寸目录名一定在该固定表里。 真实世界中常见的拼写会被漏掉：256x256@2、symbolic/、8x8、96x96 等。
3. apps/ 一定直接在尺寸目录下。 RPM 系目录树两种写法都有：48x48/apps/foo.png 与 48x48/foo.png。

vscode 带 desktopId: 'code'，所以会进入这条查找，并在上述任一条上 404。

B. 缺少 desktopId 会短路掉整条查找

extractAppIcon 中：

if (completed.platform === 'linux') {
  const desktopId = specFor(app, completed.platform)?.desktopId
  return desktopId === undefined ? null : extractLinuxIcon(desktopId, completed)
}

cursor 目录条目只声明了 linux: spec(cli('cursor'))——没有 desktopId——因此对 cursor 而言该函数立刻返回 null，一次文件系统都没碰，尽管这个应用明明已解析成功且能启动。vscode 走的则是 A 路径。两条不同代码路径，同一个占位方块。

两条路径都没有考虑应用自带安装目录内的图形（例如 resources/app/resources/linux/code.png，或解包版 VS Code 携带的 resources/app/out/media/code-icon.svg）——而这恰恰是没有安装主题包时唯一可用的图形。

建议修法

把 Linux 图标查找由「单次主题表探测」改为一组有序的文件系统轮次，并且不再把缺少 desktopId 当作「此应用没有图标」：

1. desktop 条目的图标名经活动主题、其余图标搜索路径、再 pixmaps 解析——同时容忍带版本后缀／symbolic 的尺寸目录，以及 apps/ 的两种层级。
2. 对这些主题目录做有界递归按名搜索，覆盖任意深度的图形。
3. 已验证启动器旁的打包图形，相对已解析的可执行文件（覆盖 resources/app/resources/linux/<name>.png 与 resources/app/out/media/<name>-icon.svg，并包含启动器位于上一层垫片的情形，如 bin/code）。
4. 对 XDG 数据目录做有界递归按名搜索，覆盖主题之外的厂商目录树。
5. 一小串众所周知的固定位置。

第 2、4 轮会遍历 /usr/share，因此需要深度与条目数上限，并且应当只在前面的轮次全部落空后才执行。另外 catalog.ts 需要为条目补充图形别名，因为文件名常常既不等于 catalog id 也不等于可执行文件名（vscode 条目的 code.png / code-icon.svg；cursor 条目的 Cursor.png）。目前只有 Windows 会设置的 icon: { kind: 'executable', path } 图标来源，正好可以作为 Linux 第 3 轮的锚点。

附带观察（优先级较低，同一片区域）

1. desktopId 的文档描述是「其 Icon= 键命名本应用图标的 desktop 条目」，但条目存在并不等于图标已安装。 把 desktop 条目的存在当作整条查找的闸门，正是这些情形静默失败的原因。把它降级为若干线索之一、而不是入口条件，会更稳妥。
2. 404 响应体无法区分「此应用在本机没有图形」与「没有这个应用」。 两者都返回 {"code":"not-found","message":"no icon for <id>"}，而 /open-in-app/apps 又照常列出该 id，排查成本因此被抬高。
3. xdg-open 文件管理器条目（filemanager）按设计没有任何图标来源，所以纯 CLI 安装永远显示通用占位图形。这符合预期——但这也意味着占位图形是 CLI-only 条目的常态，而不是「出问题了」的信号。
4. @deepseek-ai/dsh-native-command 的 canOpenNativePath 用 os.release() 判定 WSL（字符串含 microsoft），并为此提供了 osRelease 测试 seam；但 packages/host/open-in-app 没有转发该 seam，于是 resolveLaunch 里「WSL 还是桌面 Linux」的判断读的是跑测试那台机器的内核。转发它可以顺带让 filemanager 的桌面会话行为在测试中变得可复现。

验证说明

• 该 404 在真实主机文件系统上通过路由 handler 可确定性复现，与浏览器缓存无关。
• 浏览器表面每页只请求一次图标（packages/client/ui-open-in-app/src/client/OpenInAppAction.tsx 中的 failedIcons），因此一次 404 就会在该页锁定为占位图形。
• 对这些 id 而言 GET /open-in-app/apps 与 POST /open-in-app/open 均正常，说明探测与启动未受影响，缺陷可定位在图标提取这一环。