新建 PI 会话会重复 snapshot 大型 Pi 包并复制 rg.exe，新会话变慢40秒且残留堆积

**提交人**: 匿名
**客户端版本**: 0.1.64

---

## 现象

新建 PI 会话时，主进程会为每个会话独立准备一份运行时目录（`userData/pi-agent-home/run-tmp//`）。当前这份隔离会带来两个可观测的问题：

1. **启动极慢**：若已安装较大的 Pi 包（例如 `npm:context-mode`），从发送第一条消息到 PI 进程真正 ready 要等约 40–45 秒，界面像卡住。
2. **每次复制一份 rg 二进制**：每个新会话都会在 `run-tmp//bin/` 下落一份完整的 `rg.exe`（macOS/Linux 为 `rg`）；会话关闭后常常留下来，随使用次数堆积。

## 复现步骤

**A. 启动延迟**

1. 在 PI 包管理里安装 `npm:context-mode`（或其它带大量 `node_modules` 的 Pi 包）。
2. 新建一个 PI 会话并立刻发送一条短消息。
3. 观察从点发送到助手开始输出的等待时间。

**B. rg 复制**

1. 不管有没有 Pi 包，新建 PI 会话并发送一次。
2. 查看 `userData/pi-agent-home/run-tmp/`：每个会话目录的 `bin/` 下都会出现一份完整 ripgrep 二进制。

## 期望行为

- 新 PI 会话启动应该在几秒内就给模型发第一条请求（本机基线约 2–3 秒）。
- 超过 snapshot 预算的 Pi 包应 fail-closed 跳过，并把失败结果跨会话记住；不要每次新会话都重新 walk/copy/hash 整棵树再丢掉。
- ripgrep 可以复用已校验的管理端二进制（或硬链接），不应该为每个会话落一份完整副本并死久留在 `run-tmp`。

## 实际行为

**A.** 安装大型 Pi 包后，`startSession` 稳定耗时 40–45 秒。日志里项目 skill 装配完成到 PI stderr 之间有一段没有打点的静默窗；MCP（13 个本地 server / 56 个工具）只占约 1 秒，模型首包也不是瓶颈。本机对照：

- 未安装该包：`writeModelsJson` → MCP ready 约 2 秒。
- 安装后的多次新会话：同一间隔变成 34–45 秒。
- 卸载该包再开新会话：回到约 2.6 秒。

该包因 `inspection-limit` 被隔离快照丢掉后，**并没有装进该会话**，但每次新建仍会重做 snapshot/指纹。状态里会留下 `snapshotUnavailableRoots: inspection-limit`。

**B.** 每个新 PI 会话都 `copyFile` 一份 ripgrep 到该会话 `run-tmp//bin/`。本机观察到数十个残留目录，几乎每个都带一份约 4MB 的副本。

## 复现频率

每次新建 PI 会话都发生。A 仅在已安装大型 Pi 包时出现；B 无论有没有 Pi 包都出现。

## 已尝试

- 卸载 `npm:context-mode` 后，A 的启动延迟消失（回到约 2.6 秒），说明不是 MCP 数量或模型首包问题。
- B 的 rg 复制仍在，与该包无关。
- 启动路径上 `resolvePiManagedPackageResources` 的 inspect/copy/fingerprint/隔离没有阶段耗时日志，排查时只能靠前后时间戳。

## 建议

- inspection-limit 结果跨会话记忆，超限直接跳过，不要先拷再删。
- 给 Pi 包 snapshot 打阶段耗时日志。
- ripgrep 改为共享已校验路径或硬链接；`run-tmp` 孤儿目录要有回收。
---
**版本区域**: CN
**OS**: win32 x64 (10.0.26100)
**界面语言**: zh-CN

Start at startSession and resolvePiManagedPackageResources, using userData/pi-agent-home/run-tmp// and its bin/ directory as the observable paths. Reproduce both cases, compare the snapshot and copy/fingerprint timing, and inspect writeModelsJson-to-PI-stderr logs. Done means oversized packages are skipped and remembered across sessions, rg is reused without per-session copies, and orphaned run-tmp data is reclaimed.

Written by the indexing model from the issue text.