[Bug] Windows 会话 scratch 中的交接文本链接点击后未在右侧打开（文件引用路由待核查）

[ArturiaGit]

What happened? / 问题描述

在 Windows 上使用 PI-Desktop，Agent 将一份较长的交接文档保存到当前会话的 scratch 目录，文件格式为 UTF-8 .txt。文件存在，Agent 已通过文件读取工具核实。

Agent 在最终回复中提供了指向该文件的 Markdown 链接。用户点击后，右侧没有显示这份文本，因此无法直接在应用内查看和复制完整交接内容。

对照现象：通过 SubmitPlan 提交的计划可以在右侧显示。这里希望查看的是普通交接结果，不应为了展示而把它伪装成待审批计划。

这是一次用户反馈，尚未独立抓取点击事件、控制台日志或定位源码根因。Agent 当时把普通绝对路径链接称为“打开交接文本”，这个表述也可能造成了能力预期不一致。

Steps to reproduce / 复现步骤

1. 在 Windows PI-Desktop 的项目会话中，让 Agent 将一份合成文本保存到该会话的 scratch 目录，例如 handoff.txt。
2. 用 Read 核实文件存在且内容正确。
3. 让 Agent 在回复中输出下面形式的普通 Markdown 链接（以下路径仅为脱敏示意，复现时应换成当前会话的真实路径）：

[打开交接文本](C:/Users/Example/.pi-desktop/scratch/SESSION_ID/handoff.txt)

4. 点击该链接，观察右侧文件视图是否打开对应文本。
5. 对照一次通过 SubmitPlan 提交计划后右侧正常显示的行为。

本报告未验证 file:/// URL、工作区相对路径或其他操作系统，因此不把这些形式列为同样失败。

Expected behavior / 预期行为

对于当前会话允许访问、且确实存在的 scratch 文本文件，希望点击后复用既有的文件引用解析与宿主文件查看流程，打开正确目标，支持滚动、选择和复制完整内容。

如果这种 Markdown 链接形式不受支持，希望明确说明支持的引用方式或给出可操作的提示。也欢迎提供 Agent 可显式调用的只读“打开文本产物”入口，使交接结果、报告等不必包装为 HTML 或审批计划。

这不要求浏览器打开任意工作区外文件，不请求扩大文件权限，也不应允许跨会话读取其他 scratch 内容。

Actual behavior / 实际行为

用户反馈：点击后右侧未显示目标文本。文件本身已核实存在。

本次未记录是否弹出提示、是否打开系统默认应用或点击路由实际落在哪个处理器上，不能进一步断言是静默失败或某一具体组件缺陷。

App version / 应用版本

尚未核实；本报告不指定受影响版本，也不据此断言历史修复回归。后续可从“设置 → 信息”补充准确版本。

Operating system / 操作系统

Windows；具体 Windows 版本、安装类型和宿主协议版本尚未核实。

Related issues and scope / 相关反馈与范围

• 聊天文件引用：在主进程补全路径，并在随应用打包的文件管理插件中打开 #364 描述过：工作区文件优先进入文件管理视图，scratch/附件文件进入宿主文件标签。本次场景按该描述应已有可用承载方式，因此需要核对普通 Markdown 链接是否进入了相同解析流程。
• [Bug] 聊天无法完整识别含空格的文件路径，Windows 路径还有盘符与反斜杠问题 #1169 涉及 Windows 盘符、反斜杠和含空格路径识别。本次提供的链接使用正斜杠，不预设是同一个根因。
• [Feature] 计划/目标审批工件改用内置文件视图打开 #618 涉及计划/目标产物的打开流程，仅作体验对照。
• [Bug] 内置浏览器打不开项目外的本地文件，而且一点提示都没有 #1094 涉及浏览器对工作区外本地地址的限制与提示；本请求不要求绕过该限制。

如果当前行为属于已支持功能的用法问题，请告知推荐的 Agent 输出/打开方式；如果是现有修复的重复场景，请关联对应 Issue 或 PR。

未附真实交接文档、完整私人路径或会话 ID。临时考虑过“工作区内 HTML + BrowserPreview”，但尚未实施或实测，不作为已验证的解决方案。

[muzimu217]

在最新 main（924a03a7b）上做了代码层核查（macOS，无法直接复现 Windows 行为），先汇报链路现状——各环节都显式支持"scratch 绝对路径 .txt 链接"这个形态：

• 渲染层链接识别：apps/desktop/src/lib/chat-links.ts:41 的 FILE_TOKEN_RE 与 isAbsoluteFilePath（chat-links.ts:94）支持 C:/ 盘符正斜杠路径，txt 在 KNOWN_EXTS；
• 点击路由：apps/desktop/src/components/Markdown.tsx:661 的 Link onClick → resolvePreviewTarget → useOpenChatFileRef，绝对路径直通主进程；
• 主进程解析：fsResolveRef（apps/desktop/electron/main/ipc/workspace-ipc.ts:914）把会话 scratch 列为 allowed root 之一（优先级：项目 → scratch → attachments，见 chat-ref-resolve.ts 头注释），Windows 卷比较（couldShareVolume）与大小写不敏感匹配（CASE_INSENSITIVE_FS）都有专门处理。

也就是说最新 main 上这条链路设计上是通的。由于报告未附版本号与点击时反馈，想请报告者补充三点信息以便定位：

1. 确切版本（设置 → 信息），确认是否早于上述链路成形；
2. 点击瞬间是否出现 toast（如"找不到文件 / 不在允许范围"）——use-preview-target.ts:113 在解析失败时必出 toast，"完全无反馈"和"有 toast 但未打开"指向不同环节；
3. 若方便，DevTools 控制台有无报错。

另外给出两个我在核查中注意到的候选根因，供复现时对照：

• 会话已切换后点击：scratch root 取自 sessionScratchRoot(input.sessionId) 的当前活跃会话，若点击发生在切换到别的会话之后，目标路径不在任何 allowed root 内 → outside-allowed-roots → 应有 toast；
• Windows 目录 junction / OneDrive Known Folder Move 重定向：isChatRefOutsideRoots（chat-ref-resolve.ts:200）对 target 与 root 都做 realpath 后再比较，若用户目录经 junction 重定向，物理路径可能不再位于 scratch root 的 realPath 之下 → 误判为 outside。若复现属于这种（且确有 toast "restricted"），那是解析层值得修的真实 bug。

若核实属于其中之一，欢迎带版本号和 toast 文案回来，我们按结果分流处理。

[ArturiaGit]

感谢核查，补充 Windows 实机信息：

• 应用版本：PI-Desktop 0.16.1，protocol 11 / host 0.16.1，来自“设置 → 信息”截图。
• 重新点击指向会话 scratch 中现有 .txt 文件的 Markdown 链接后，右侧没有打开文件，没有观察到 toast 或其他可见反馈。
• 查看 DevTools Console，未观察到本次点击产生的新消息或报错。

实际失败的链接形式如下（文件此前已通过 Read 核实存在；报告者已明确同意公开这条本地路径）：

[打开交接文本](C:/Users/Administrator/.pi-desktop/scratch/ad5c8197-215f-42c0-9235-f50eb3eb850f/TASK-APP-002-E5-prompt.txt)

该路径仅指向报告者本机文件，不是可供他人访问的下载地址；未上传文件内容。

根据你提供的链路说明，解析失败通常应出现 toast；本次没有可见提示，希望优先核查 0.16.1 发布版中，这种 C:/.../*.txt Markdown 链接是否进入 Link onClick → resolvePreviewTarget → useOpenChatFileRef 流程。这是排查建议，不是已定位的根因；尚未核实 0.16.1 发布版与 main 的 924a03a7b 是否一致。

是否曾切换会话、目录是否存在 junction / OneDrive 重定向尚未单独确认，因此暂不据此判断原因。Console 没有消息也不能证明点击处理正常。

如果需要进一步诊断，请告知建议的点击断点或日志采集位置，我可以继续补充 Windows 实测结果。

[muzimu217]

感谢实机信息，非常关键。"无 toast + 无 console 输出"这个组合本身就有诊断价值：渲染层链路上解析失败必出 toast（use-preview-target.ts:113 的 fileRefMissing/fileRefRestricted），IPC 失败也有 fileRefLookupFailed 兜底。两者都没有，最可能的落点是：

• Link onClick（Markdown.tsx）里 ref 为 null → 走不到 preventDefault()，浏览器默认行为（target="_blank" 打开一个非 http 的 href）被主进程窗口策略静默吞掉——完全静默，与你观察到的现象一致；或者
• 点击根本没进这个 handler（链接没有被渲染成带该 href 的锚点）。

你问的"0.16.1 发布版中是否进入 Link onClick → resolvePreviewTarget → useOpenChatFileRef 流程"正是对的问题：0.16.1 与最新 main 的 chat 链接实现有实质重构差异（main 引入了新的扫描预算模块、session-link token 等），我们在 main 上核对"链路是通的"的结论不能直接套用到 0.16.1。

建议的采集位置（Windows 实机，两步）

第 1 步（不用断点，Console 跑一行）——确认 DOM 形态：

[...document.querySelectorAll('a')].filter(a => (a.getAttribute('href') || '').startsWith('C:')).map(a => a.getAttribute('href'))

• 列表里有那条 scratch 链接 → 锚点渲染正常，继续第 2 步；
• 空数组 → 链接根本没被识别成文件锚点（另一类根因，把该消息的原始 markdown 发我）。

第 2 步（Sources 断点）——DevTools → Sources → Ctrl/Cmd+P 打开 Markdown.tsx → 搜索注释 Plain click follows 定位 Link 的 onClick → 在函数首行下断点 → 点那条链接，记录三件事：

1. href 的实际值；
2. resolvePreviewTarget(decoded, root, baseDir) 的返回值；
3. 是否走进 if (ref) 分支。

结果含义对照：

断点观察	结论
断点根本不触发	点击没进 handler（渲染/包装层问题）
ref === null	0.16.1 渲染层解析失败——把 decoded、root、baseDir 三个值发我，可以在 v0.16.1 的代码上精确复现是哪一步返回了 null
ref 有值、无 toast、右侧没开	主进程 fsResolveRef/preload 在 0.16.1 的链路缺段——这与 main 的差异对比就是实锤

另外说明：main 上这条链路我们已核对是通的，所以如果断点显示 0.16.1 在渲染层解析就失败，下一版发布后用同一文件复测也是有效对照。欢迎带着断点结果回来。

[muzimu217]

进展通报：维护者刚刚在 main 落了一个直接相关的修复 fa2bd8389 "fix(files): open a scratch path another session wrote"，方向与本 issue 高度吻合：

• fsResolveRef 现在给绝对路径的 containment 检查放宽到整个 scratch store（workspace-ipc.ts 传入 containment: [{ kind: "scratch", path: <dataDir>/scratch }]），而不再只认"当前活跃会话"自己的 scratch 目录；
• 同时 fsRead / fsOpen / 图片读取 / fsReveal 等 read guard 都接受整个 store。

这正好覆盖我们此前列的候选根因一——会话已切换后点击：sessionScratchRoot(input.sessionId) 取的是"当前活跃会话"，如果你是在 Agent 写完交接文档后切换到别的会话（或新开会话）再点链接，0.16.1 的解析会把该路径判为 outside allowed roots。你提到"是否曾切换会话尚未单独确认"——如果复现时确实切过会话，这个修复应该就是答案。

请复测：该修复目前在 main（cfef0dcd5），尚未进正式发布版。两个复测路径任选：

1. 等下一个含此提交的 release（可订阅 releases 页）；
2. 从源码构建 main 后用同一文件复现（pnpm install && pnpm build，Windows 构建说明见仓库 docs）。

若在新代码上仍完全静默（无 toast、右侧不开），那就是渲染层问题了——请按我上一条回复的两步采集（Console 锚点探测 + Markdown.tsx onClick 断点）把 href / resolvePreviewTarget 返回值带回来，我们再往渲染层挖。

[ArturiaGit]

已升级至 PI-Desktop 0.17.0，使用同一 .txt 文件重新测试，点击完整路径的 Markdown 链接后，仍没有任何可见反馈，右侧未打开。

本次重新输出的链接原始 Markdown 为：

### [打开 TASK-APP-002-E5 完整交接文本](C:/Users/Administrator/.pi-desktop/scratch/ad5c8197-215f-42c0-9235-f50eb3eb850f/TASK-APP-002-E5-prompt.txt)

文件在本次重测前已通过 Read 再次确认存在。该完整本地路径此前已授权公开，未上传文件内容。

为避免仅按 href.startsWith('C:') 查询时遗漏已经丢失 href 的元素，在 DevTools Console 执行了下面的只读 DOM 查询：

[...document.querySelectorAll('a')]
  .filter(a =>
    (a.getAttribute('href') || '').includes('TASK-APP-002-E5-prompt.txt') ||
    (a.textContent || '').includes('完整交接文本')
  )
  .map(a => ({
    text: a.textContent,
    href: a.getAttribute('href'),
    html: a.outerHTML
  }))

实机返回结果如下：

[
    {
        "text": "TASK-APP-002-E5-prompt.txt",
        "href": "TASK-APP-002-E5-prompt.txt",
        "html": "<a href=\"TASK-APP-002-E5-prompt.txt\" target=\"_blank\" rel=\"noopener noreferrer\"><button type=\"button\" class=\"chat-code-link\" title=\"在侧边面板预览\"><code data-source-start=\"128\" data-source-end=\"156\">TASK-APP-002-E5-prompt.txt</code></button></a>"
    },
    {
        "text": "打开 TASK-APP-002-E5 完整交接文本",
        "href": null,
        "html": "<a data-source-start=\"48\" data-source-end=\"183\" target=\"_blank\" rel=\"noopener noreferrer\">打开 TASK-APP-002-E5 完整交接文本</a>"
    }
]

关键观察：实际点击的完整路径 Markdown 链接被渲染为没有 href 属性的 <a>，getAttribute('href') 返回 null。 另一处文件名引用有相对 href 和 chat-code-link 按钮，它是不同的 DOM 元素，尚未验证其点击结果，不能当作完整路径链接正常的证据。

请优先核查完整路径 Markdown 链接的 URL 转换／安全过滤是否移除了 C:/... 目标，以及点击处理是否因此无法取得有效文件引用。C: 被识别为 URL scheme 是一个候选方向，尚未核查源码或确认根因；也未采集 onClick 断点及 resolvePreviewTarget 的返回值。

0.17.0 本次点击后仅确认无可见反馈；没有重新单独记录点击产生的 Console 消息。以上 DOM 查询结果是新采集的证据，不将 0.16.1 的 Console 观察直接套用到新版本。

如果还需要进一步的 Sources 断点信息，请告知适合 0.17.0 发布版的具体定位方式。

[muzimu217]

跟进：该修复已随 v0.17.0 正式发布（release 包含 fa2bd8389，本地 git tag --contains 已验证）。可以直接下载 v0.17.0 用同一文件复测，不用再从源码构建；若仍完全静默，再按前一条回复的断点指引采集 href / resolvePreviewTarget 返回值即可。

[muzimu217]

跟进一个好消息：这条的根因已经被官方定位并修复了。

修复是 #1470（fix(markdown): preserve Windows file links，已进 main）。提交说明与你观察到的现象逐字吻合："带盘符的 Markdown 目标在文件打开器接手之前就被当作 URI scheme 过滤掉了"——C:\Users\...\.pi-desktop\scratch\... 这类链接点击后完全静默、右侧不打开，正是这个原因。修复做了两件事：Markdown 渲染阶段把绝对 Windows 路径编码保留下来（不再被 scheme 过滤吞掉），点击时经既有文件打开通道解码处理，净化与文件访问检查保持不变。附带 102 行新测试与 E2E 场景更新。

也解释了为什么 v0.17.0 复测仍然失败：该修复合并于 0.17.0 发布之后（本地 git tag --contains 27da36b03 为空，不在任何发布 tag 内）。

下一步：等下一个发布版本（或从 main 自行构建）后，用同一个 .txt 文件复测即可。如果届时仍静默，我们再回到之前给出的断点采集路径（href / resolvePreviewTarget 返回值）。