8.4 KiB
8.4 KiB
Cursor 自动关闭问题 · 日志分析与处理记录
日期：2026-03-04（2026-03-05 补充弹窗与操作说明）
现象：Cursor 经常莫名自动关闭（俗称「咳嗽自动关闭」），随后弹出 「The window is not responding」 弹窗。
原则：不关闭硬件加速，保留视频/剪辑等所需能力，从根因入手。
零、弹窗「The window is not responding」出现时怎么选
当出现系统弹窗 「The window is not responding」（窗口没有响应）时：
| 选项 | 建议 |
|---|---|
| Reopen（重新打开） | 推荐。先勾选 「Don't restore editors」（不恢复编辑器），再点 Reopen，可避免恢复可能已损坏的编辑器状态，减少再次卡死。 |
| Close（关闭） | 若不需要保留当前窗口，可直接关闭。 |
| Keep Waiting（继续等待） | 仅当你在等某次操作完成时可选；若已卡很久，建议选 Reopen 并勾选 Don't restore editors。 |
该弹窗与第一节中的「窗口无响应」「渲染进程崩溃」属同一类问题，根因与缓解方式见下文。
一、日志结论与根因
-
日志路径：
~/Library/Application Support/Cursor/logs/（按会话分目录，如20260304T190511） -
直接表现：
- 渲染进程崩溃（code 5）：
CodeWindow: renderer process gone (reason: crashed, code: 5)，随后主进程未捕获异常Render frame was disposed before WebFrameMain could be accessed，导致整个应用退出。 - Agent 分析 SQLite 报错：
[AgentAnalyticsOperationsMainService] Error ... SQLITE_ERROR: cannot start a transaction within a transaction（嵌套事务），在「存储 AI code hashes / marking commits as scored」时反复出现，可能加剧不稳定。 - 窗口无响应：
CodeWindow: detected unresponsive后有时恢复，有时被关掉。 - ptyHost 心跳超时：
No ptyHost heartbeat after 6 seconds，终端相关进程偶发无响应。
- 渲染进程崩溃（code 5）：
-
根因（社区与日志综合）：
- code 5 在 macOS 上多与 V8/JS 内存（OOM）、GC 压力、以及 macOS mach port 通知失败 有关，不一定与 GPU 驱动有关；硬件加速已保留，不通过关闭它来规避。
- AgentAnalyticsOperationsMainService 的嵌套事务是 Cursor 端 bug，需等官方修复或通过清理该服务数据缓解。
二、已做处理（不限制功能）
-
保持硬件加速开启
~/.cursor/argv.json中 未 启用disable-hardware-acceleration，视频/剪辑相关能力不受影响。
-
本机已有设置
cursor.general.enableCodebaseIndexing": false已关闭，减轻后台索引压力。
三、今日（3/4）日志复检结论
- 会话数：3 月 4 日共有 11 个 Cursor 日志会话（12:38～21:58），说明今日多次重启/自动关闭。
- 重复出现的错误：
CodeWindow: detected unresponsive、UnresponsiveSampleError（窗口无响应后可能被关掉）；AgentAnalyticsOperationsMainService的SQLITE_ERROR: cannot start a transaction within a transaction在多个会话中反复出现；Extension host 多次正常退出（code 0），可能伴随窗口重载。 - 结论：根因与文档第一节一致，无新类型；缓解手段仍为减轻内存压力 + 清理缓存 + 等官方修复。
四、建议操作（不关功能、从根因缓解）
- 减轻内存压力：少开不需要的窗口/工作区、关掉不用的标签页；大项目可考虑单独开一个 Cursor 窗口，避免单进程负载过大。当前若打开了多个工作区根（如 个人、卡若AI、聊天记录、开发、婼瑄 等），文件监视与扩展会加重负担，可尝试只保留当前要用的 1～2 个文件夹再打开 Cursor。
- 清理缓存（推荐）：完全退出 Cursor（Cmd+Q）后在终端执行以下任一方式，再重新打开 Cursor，可减轻 OOM/旧缓存导致的崩溃：
- 方式一（一键脚本）：
bash "/Users/karuo/Documents/个人/卡若AI/运营中枢/参考资料/scripts/clear_cursor_cache.sh"
脚本会检测 Cursor 是否在运行：若在运行会提示先退出再执行；若已退出则自动清理 GPUCache 与 Cache。 - 方式二（直接命令）：
若 Cursor 正在运行，请先 Cmd+Q 完全退出再执行。rm -rf ~/Library/Application\ Support/Cursor/GPUCache ~/Library/Application\ Support/Cursor/Cache - 方式一（一键脚本）：
- 向 Cursor 官方反馈：把闪退时间段的
main.log（含 code 5、Render frame disposed、AgentAnalytics SQLITE_ERROR）提交到 Cursor Forum 或官方支持，便于他们修 code 5 与 SQLite 嵌套事务。 - 保持 Cursor 更新：当前 2.6.11，后续版本可能修复上述问题。
若官方或社区后续提供「增加 JS 堆大小」等 argv 支持，再在 argv.json 中按文档配置，无需关闭硬件加速。
五、日志位置速查
| 内容 | 路径 |
|---|---|
| 主进程日志 | ~/Library/Application Support/Cursor/logs/<会话目录>/main.log |
| 窗口日志 | 同上目录下 window1/、window2/ 等 |
| 启动参数 | ~/.cursor/argv.json |
六、本次（3/5）全面检查结论
- 弹窗对应关系：「咳嗽自动关闭」后出现的 「The window is not responding」 与日志中的
CodeWindow: detected unresponsive一致，属同一类问题；按「零、弹窗出现时怎么选」操作即可。 - 本机状态：Codebase Indexing 已关、硬件加速保留；
workspaceStorage约 2.7G、CachedData约 413M，定期清理 GPUCache + Cache 有助于缓解。 - 已做：① 在文档中补充弹窗操作说明与「Don't restore editors」建议；② 新增一键清理脚本（见四、方式一），便于退出 Cursor 后执行。
- 你可立即做的：下次弹窗时勾选「Don't restore editors」再点 Reopen；在方便时 Cmd+Q 退出 Cursor，执行上述清理脚本或命令后重开。
七、3/12 深度修复（终极解决 code 5 反复崩溃）
诊断数据
| 指标 | 数值 | 严重程度 |
|---|---|---|
| 当日崩溃次数 | 3 次（4 个会话） | 🔴 严重 |
| SQLite 嵌套事务错误 | 99 次/天 | 🔴 严重 |
| state.vscdb 大小 | 15GB（正常 <100MB） | 🔴 根因 |
| state.vscdb.backup | 14GB | 🔴 浪费空间 |
| workspaceStorage | 2.8GB / 110 条目（78 条过期） | 🟡 |
| CachedData | 583MB | 🟡 |
| 日志 | 503MB | 🟡 |
| JS 堆上限 | 未设置（默认 ~1.5GB） | 🟡 |
| 同窗口工作区 | 7 个根目录 | 🟡 加重负担 |
根因定位
state.vscdb（Cursor 全局状态数据库）膨胀到 15GB 是崩溃的终极元凶。
cursorDiskKV表积累了 103 万行 / 13.7GB 数据（正常应 <50MB）- 该数据库大到连查询都报
database or disk is full - 每次 Cursor 读写此库都极度吃力，引发：V8 OOM → renderer crash code 5 → 窗口无响应 → Reopen 弹窗
- AgentAnalytics 的 SQLite 嵌套事务错误也与此膨胀数据库有关
已执行修复
| # | 修复项 | 效果 |
|---|---|---|
| 1 | argv.json 加 --max-old-space-size=8192 |
V8 堆上限从 ~1.5GB → 8GB，防 OOM |
| 2 | 清理 78 个过期 workspaceStorage | 释放 1084MB |
| 3 | 创建深度修复脚本 cursor_deep_fix.sh |
一键重置 state.vscdb + 全面清理 |
待用户执行（需关闭 Cursor）
Cmd+Q 退出 Cursor → 终端执行：
bash "/Users/karuo/Documents/个人/卡若AI/运营中枢/参考资料/scripts/cursor_deep_fix.sh"
此脚本会：
- 将 15GB 的 state.vscdb 移到废纸篓备份（Cursor 重启自动重建干净数据库）
- 清理 GPUCache / Cache / CachedData
- 清理 >7 天旧日志 + >30 天过期工作区
- 清理 Crash Reports
预计释放 ~30GB（15GB state.vscdb + 14GB backup + 583MB CachedData + 其余缓存）。
脚本位置
| 脚本 | 路径 | 用途 |
|---|---|---|
| 深度修复（推荐） | 运营中枢/参考资料/scripts/cursor_deep_fix.sh |
重置膨胀数据库 + 全面清理 |
| 轻量清理 | 运营中枢/参考资料/scripts/clear_cursor_cache.sh |
仅清 GPUCache/Cache/CachedData |
预防措施
argv.json已设--max-old-space-size=8192（重启生效），防止 V8 堆溢出- 建议每 2 周执行一次轻量清理脚本；若出现崩溃则执行深度修复脚本
- 尽量减少同窗口工作区数量（当前 7 个，建议控制在 3 个以内）