提交前确认 · Pre-submission checklist
问题类别 · Category
稳定性 / 崩溃 · Stability / Crash（崩溃上报链路本身）
涉及的 Agent 框架 · Agent framework
不涉及框架 · Not framework-specific（崩溃点在 Electron 自带的 crashpad handler 子进程）
严重程度 · Severity
影响体验 · Major（不阻塞功能，但会让崩溃转储静默丢失，直接损害定位崩溃的能力）
复现频率 · Reproducibility
偶现但成串出现 · Sometimes, in bursts
问题描述 · Description
ZCode 包内的 Crashpad 处理器（ZCode.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Helpers/chrome_crashpad_handler）在 macOS 上自己反复崩溃，2 天内 75 次，且高度成串：
| 时段（本机时间） |
次数 |
| 2026-10-02 13:40:30 – 13:56:19 |
24 |
| 2026-10-02 14:39:43 |
1 |
| 2026-10-03 08:00:39 – 08:16:41 |
50（约每 20 秒一次） |
每份 ~/Library/Logs/DiagnosticReports/chrome_crashpad_handler-*.ips（macOS 自带 ReportCrash 产出）显示同一形态：
- 异常：
EXC_BREAKPOINT / SIGTRAP，exception.codes = 0x1, 0x1046e66c4
- 存活时长 ≈ 123–126 ms（
procStartAbsTime → procExitAbsTime），即启动后立刻死
parentProc = launchd、responsibleProc = ZCode、coalitionName = dev.zcode.app- 崩溃线程（已符号化，image 0 = chrome_crashpad_handler）：
CrashpadHandlerMain 内的多个偏移，栈底 dyld: start
影响：处理器进程死了，需要它记录的崩溃就无法落盘/上传（App 日志显示 remoteCrashReporterEnabled=true，[crash-capture] 归档依赖这条链路）。上述两个时段内 ~/.zcode/v2/crash/archive/ 没有任何新增 dump——无法区分"当时确实没崩"与"崩了但写不出 dump"，即这两段时间的崩溃证据不可信（可能已被静默吞掉）。
对照事实（说明不是 App 主进程在崩）：
- 两个时段内主进程始终是同一个 pid 并在持续正常写日志；
- 日志中没有
render-process-gone、没有 perf_crash，也没有异常终止的子进程（该窗口内 14 次 ZCode agent process exited 全为 code:0 / terminationKind:"expected" / terminationReason:"manager-dispose"）；
- App 自身的
[crash-capture] 在该时段没有任何 archived N dump(s) 记录。
也就是说：处理器被反复拉起、反复崩（约每 20 秒一次），但"谁在反复拉起它、为什么它一启动就崩"从 App 侧日志看不出来，需要你们从 handler 侧确认（怀疑与上一次崩溃遗留的 database/锁、或 handler 启动参数有关）。
补充：这条链条也影响你们排查崩溃类 issue 的效率——例如 #342 这类"主进程崩溃"报告，如果恰好落在 handler 崩溃的时段，dump 会缺失。macOS 自带的 .ips 是目前唯一还能拿到现场的通路。
复现步骤 · Steps to reproduce
无法按需复现（偶发、成串出现）。观测到的条件：macOS 桌面端常驻使用（含内嵌浏览器 / agent 会话活动）。如果需要，我可以加一个监控脚本，在 .ips 再次出现时立刻抓取现场（进程树、spawn 参数、当时的 ZCode 日志切片）并附上。
期望表现 · Expected behavior
Crashpad 处理器应稳定常驻；即使它异常退出，宿主也应在下一次崩溃时重新拉起并成功写盘，崩溃转储不应丢失。
实际表现 · Actual behavior
处理器每次被拉起后约 126 ms 即 EXC_BREAKPOINT 崩溃，成串出现（16 分钟内 50 次），该时段的崩溃转储缺失。
ZCode 版本 · ZCode version
3.14.4 (3.14.4.7912)（当日 [auto-update] 检查已是 latest）
设备 / 系统 / 浏览器 · Device / OS / Browser
Apple Silicon arm64 / macOS 15.6 (24G84) / ZCode Desktop
截图 / 录屏 / 日志 · Screenshots / Recordings / Logs
- 75 份
.ips 在本机 ~/Library/Logs/DiagnosticReports/，文件名格式 chrome_crashpad_handler-<YYYY-MM-DD-HHMMSS>.ips；
这些文件含机器标识（crashReporterKey / incident_id 等），我默认不上传公开仓库，需要时我可以脱敏后提供；
- 上面引用的字段（异常、时长、进程关系、符号化栈）均逐字来自这些文件；
- 也可提供
~/.zcode/v2/logs/2026-10-02.log / 2026-10-03.log 对应时段的切片。
提交前确认 · Pre-submission checklist
crashpad、minidump均无同类；[Bug] Windows 桌面端 3.8.1：内置浏览器(browser-use)标签页销毁时主进程空指针写入崩溃 0xC0000005 @ ZCode.exe+0x174C2F2（升级后 3 分钟内 2 次） #342 是内嵌浏览器 guest 销毁时主进程崩溃，本条是崩溃处理器自身崩溃，属不同组件）问题类别 · Category
稳定性 / 崩溃 · Stability / Crash（崩溃上报链路本身）
涉及的 Agent 框架 · Agent framework
不涉及框架 · Not framework-specific（崩溃点在 Electron 自带的 crashpad handler 子进程）
严重程度 · Severity
影响体验 · Major（不阻塞功能，但会让崩溃转储静默丢失，直接损害定位崩溃的能力）
复现频率 · Reproducibility
偶现但成串出现 · Sometimes, in bursts
问题描述 · Description
ZCode 包内的 Crashpad 处理器（
ZCode.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Helpers/chrome_crashpad_handler）在 macOS 上自己反复崩溃，2 天内 75 次，且高度成串：每份
~/Library/Logs/DiagnosticReports/chrome_crashpad_handler-*.ips（macOS 自带 ReportCrash 产出）显示同一形态：EXC_BREAKPOINT / SIGTRAP，exception.codes = 0x1, 0x1046e66c4procStartAbsTime → procExitAbsTime），即启动后立刻死parentProc = launchd、responsibleProc = ZCode、coalitionName = dev.zcode.appCrashpadHandlerMain内的多个偏移，栈底dyld: start影响：处理器进程死了，需要它记录的崩溃就无法落盘/上传（App 日志显示
remoteCrashReporterEnabled=true，[crash-capture]归档依赖这条链路）。上述两个时段内~/.zcode/v2/crash/archive/没有任何新增 dump——无法区分"当时确实没崩"与"崩了但写不出 dump"，即这两段时间的崩溃证据不可信（可能已被静默吞掉）。对照事实（说明不是 App 主进程在崩）：
render-process-gone、没有perf_crash，也没有异常终止的子进程（该窗口内 14 次ZCode agent process exited全为code:0 / terminationKind:"expected" / terminationReason:"manager-dispose"）；[crash-capture]在该时段没有任何archived N dump(s)记录。也就是说：处理器被反复拉起、反复崩（约每 20 秒一次），但"谁在反复拉起它、为什么它一启动就崩"从 App 侧日志看不出来，需要你们从 handler 侧确认（怀疑与上一次崩溃遗留的 database/锁、或 handler 启动参数有关）。
补充：这条链条也影响你们排查崩溃类 issue 的效率——例如 #342 这类"主进程崩溃"报告，如果恰好落在 handler 崩溃的时段，dump 会缺失。macOS 自带的
.ips是目前唯一还能拿到现场的通路。复现步骤 · Steps to reproduce
无法按需复现（偶发、成串出现）。观测到的条件：macOS 桌面端常驻使用（含内嵌浏览器 / agent 会话活动）。如果需要，我可以加一个监控脚本，在
.ips再次出现时立刻抓取现场（进程树、spawn 参数、当时的 ZCode 日志切片）并附上。期望表现 · Expected behavior
Crashpad 处理器应稳定常驻；即使它异常退出，宿主也应在下一次崩溃时重新拉起并成功写盘，崩溃转储不应丢失。
实际表现 · Actual behavior
处理器每次被拉起后约 126 ms 即
EXC_BREAKPOINT崩溃，成串出现（16 分钟内 50 次），该时段的崩溃转储缺失。ZCode 版本 · ZCode version
3.14.4 (3.14.4.7912)（当日
[auto-update]检查已是 latest）设备 / 系统 / 浏览器 · Device / OS / Browser
Apple Silicon arm64 / macOS 15.6 (24G84) / ZCode Desktop
截图 / 录屏 / 日志 · Screenshots / Recordings / Logs
.ips在本机~/Library/Logs/DiagnosticReports/，文件名格式chrome_crashpad_handler-<YYYY-MM-DD-HHMMSS>.ips；这些文件含机器标识（crashReporterKey / incident_id 等），我默认不上传公开仓库，需要时我可以脱敏后提供；
~/.zcode/v2/logs/2026-10-02.log/2026-10-03.log对应时段的切片。