Qoder CN IDE 1.36.0：WSL2 冷启动后 Agent 面板空白且无法自愈

【版本指纹】
cosyVersion 1.36.0 | Qoder CN IDE 1.36.0（2026-10-23 17:20 升级）| 远程 server commit 79ce8d8dc4c63446f2196a83280615391a43064d（2026-10-24 11:44 部署）| aicoding-agent 扩展 version 1.0.0
故障时间：2026-10-24 13:42 首次出现 → 2026-10-26 09:50 仍复现（此后每次 WSL 冷启动 100% 复现）
数据目录：~/.config/QoderCN/SharedClientCache

【一句话结论】
1.36.0 新增的「唯一属主(owner)声明与抢占守卫」把 WSL2 每次冷启动必然变化的 boot_id 当成了「另一个 Linux 环境持有的锁」，于是同时决定：不起新 agent + 不清陈旧门牌，只留一句「已暂停自动清理，每分钟复查」无限空转。表现为每次开机后 Agent 面板空白、历史会话列表为空、执行 Skill 报「无法连接」，且软件内部无任何自救路径。

【环境】
连接形态：Windows → WSL2 远程工作区（非 Remote SSH）。WSL 内核 5.10.16.3-microsoft-standard-WSL2（inbox WSL，wsl.exe 不支持 --version），Ubuntu 24.04.1 LTS。主机名 LAPTOP-ANARUPVH。工作区在 ext4（/home/...，非 /mnt/c）。
当前 boot_id = e36e8917-c2ca-4d6a-9e3e-d3ceb77f345a，pid namespace = pid:[4026532214]。

【复现步骤】
1) WSL2+Ubuntu 24.04，用 1.36.0 打开 WSL 工作区，确认 agent 已运行（SharedClientCache/.info.json 内有 pid）；
2) 正常关机或执行 wsl --shutdown；
3) 重新开机，直接打开 Qoder 窗口（先不要开任何终端）；
4) 观察 Agent 面板。
期望：扩展发现记录的 agent PID 在当前 boot 内已不存在 → 清理陈旧端点 → 重拉 agent → 面板正常。
实际：面板空白。既不接管也不清理，每分钟复查一次，永不退出该状态。必须手工删除 .info / .info.json / .lock / .process-meta.json / .aicoding-cosy-owner.json / qodercn.sock 这 6 个文件才能恢复，且下次冷启动 100% 复发。

【根因】（基于 extensions/aicoding-agent/dist/extension.js 反混淆，标识符保持原样）
1) boot 上下文仅在 linux 采集：f() 读 /proc/self/ns/pid 与 /proc/sys/kernel/random/boot_id。
2) bootId 不一致即判外部启动 → 暂停自动清理：
t.pendingStartupEnded=function(e,t){const r=f(),n=e.hostname===A.hostname()&&e.platform===process.platform; if(n&&e.bootId&&r.bootId&&e.bootId!==r.bootId)return true; ...}
对应 .aicoding-startup-pending.json（常量 g=6e5 即 10 分钟）。这就是「已暂停自动清理，每分钟复查」的实现来源。
3) owner 抢占用 pidNamespace 一票否决：
if(n.pidNamespace!==t.pidNamespace||("linux"===t.platform&&!t.pidNamespace)) return {reclaimed:false,reason:"owner PID namespace differs or cannot be verified"};
存活判断在其之后才发生：process.kill(n.pid,0) 抛 ESRCH → {reclaimed:true,reason:"previous owner exited"}，否则 {reclaimed:false,reason:"owner PID is alive or its exit cannot be verified"}。
关键问题：bootId / pidNamespace 两道判定都排在存活判断之前，导致「属主进程已随上次 boot 死亡」这一最该触发清理的事实根本没机会被评估。

【现场证据】
A. 陈旧 owner 文件实拿（10/24 boot 留下，手工清理前的备份内容）：
{"version":1,"pid":1445,"uid":1000,"startTime":"25979","scope":{"hostname":"LAPTOP-ANARUPVH","bootId":"b8d898cc-c66f-4ee9-8782-4adb0852bf98","pidNamespace":"pid:[4026532214]"},"publication":{"device":"2064","inode":"172487","digest":"83d0bb4492aa3bf0e6c049ad3a51e16d883bfc8980c0015ee91ac90bf835be65"}}
与本次 boot 对照：bootId b8d898cc… → e36e8917…（必然不同）；pidNamespace 两次完全相同（都是 pid:[4026532214]）；pid 1445 当前已不存在。
推论一：WSL2 的 pid namespace 编号跨 boot 不唯一，因此 pidNamespace 校验在 WSL2 上不具判别力，实际只有 bootId 在起作用，而 bootId 在 WSL 下每次开机都变，没有例外。
推论二（比 bootId 误判更严重）：WSL 每次冷启动 PID 重新编号，上个 boot 记录的 pid（本例 1445）在新 boot 里很可能已被一个完全无关的进程占用，process.kill(pid,0) 返回成功 → 判为 alive → reclaimed:false → 永久无法接管，连重启都救不了。
B. 回归引入时间线（~/.qoder-cn-server/bin/ 每个 hash 目录 = 一次 server 部署，检索其中 extension.js 是否含 aicoding-cosy-owner）：
08-08 ee503033 无 / 08-08 74db3afc 无 / 09-28 85e509d9 无 / 10-09 36687ddc 无 / 10-14 e79bef68 无 / 10-17 b98cae71 无 / 10-20 23:21 55d1b69e 首次出现 / 10-24 11:44 79ce8d8d 有（当前在用）。
结论：该守卫随 1.36.0 系列在 2026-10-20 ~ 10-24 引入，此前版本不存在。这解释了「以前从来没有，现在每次开机都来一次」。另核对更新日志，其中「修复 Windows 运行时冷启动误判」「修复残留进程导致 Windows 安装被误判阻断」两条均属 Qoder 桌面端 0.1.0（2026-08-27），与本问题无关，即本回归目前尚未被认领。
C. 触发频率（Windows 系统日志 Get-WinEvent，近 30 天）：boot(id12)=66、shutdown(id109)=29、initiated(id1074)=29、dirty(id41)=3；近 60 天 boot=130、shutdown=61。同期 Hyper-V-VmSwitch 事件 1445 条、Hyper-V-Hypervisor 320 条，远多于 Windows 开机次数，说明 WSL2 轻量 VM 每天被停止/重建多次（空闲回收、休眠唤醒、wsl --shutdown）。每一次都换 boot_id → 每一次都命中守卫。对日常重度用户属于「每天必现」。
D. 数据未受损（用于排除误判为数据库故障）：cache/db/local.db 实测 44 会话 / 10114 消息可读；state/database-health.json = {"status":"healthy","cosyVersion":"1.36.0"}。本问题是 agent 未被拉起 + UI 卡在失败握手，不是数据丢失。

【修复建议】
1) 存活判断前置：只要能确定记录的 owner PID 在当前 boot 内不存在（ESRCH，且 /proc/ 的启动时间与 owner 记录里的 startTime 不吻合即判为 PID 复用而非同一进程），就直接 reclaimed:true 清理并接管。不要把 bootId/pidNamespace 校验做成前置一票否决。
2) 不要单靠 bootId 判 foreign 环境：WSL2 每次冷启动 boot_id 必变，但 hostname、uid、数据目录都没变，这是「同一个环境的上一世」，不是「别人的环境」。建议 hostname+platform+uid+数据目录 inode 全等时视为同环境残留、允许清理，仅在这些标识不等时才按 foreign 处理。
3) pidNamespace 校验在 WSL2 上无效，需换判据：叠加 /proc//stat 的 starttime 与 owner 记录里的 startTime 做交叉验证，防 PID 复用被误判为 alive。
4) 给「每分钟复查」加逃生出口：连续 N 次（如 3 次 = 3 分钟）复查后仍判定 foreign 且属主进程不可达 → 自动降级为「备份后清理并接管」，只在日志记一条 WARN，不再向用户弹窗。
5) 用户可见文案需要修正：「请使用独立的数据库目录」把软件自身缺陷描述成了用户配置错误，用户只会去做「真的换一个数据库目录」这种破坏性动作。建议改为「检测到上一次运行残留的连接信息，已自动清理并重连」；确需人工干预时明确列出「删除以下 6 个文件即可恢复」并提供内置一键清理。
6) 提供内置兜底命令，例如 Qoder: Repair agent connection，逻辑即上述 6 个端点文件的备份+删除。不要让「删掉 6 个可牺牲的端点文件」这种事必须由用户绕过 GUI 完成——部分用户甚至没有可用的终端入口。
补充：外部 workaround（已在用户侧生效）是在 ~/.bashrc 挂钩子，开机后首次开终端时比对 boot_id 与 owner.bootId，不匹配则备份并删除 6 个端点文件，扩展在下一个 60s 重试周期自动重拉 agent。残余缺陷是：若开机后只开 Qoder 窗口、始终没开终端，问题依旧——这正是必须从扩展内部修的原因。

【验收标准】
WSL 冷启动后首次打开 Qoder 窗口、且不开任何终端，Agent 面板在 agent 拉起超时（建议 ≤60s）内自行恢复，历史会话列表完整，无「请使用独立的数据库目录」类误导弹窗；~/.config/QoderCN/SharedClientCache/ 下 6 个端点文件被自动重建，local.db 内容零丢失。