Cursor 长会话 renderer 崩溃怎么办
2026-09-01 Cursor 员工确认长 Agent 会话大量编辑和 diff 会抬高渲染进程内存直至崩溃。先处理挂起改动，接近上限再 Reload Window。
cursor 长会话 renderer 崩溃怎么办：2026-09-01 Cursor 员工 Kevin Neilson（论坛账号 kevinn）在帖子里写，这是他们在跟的已知问题：长 Agent 会话产出大量编辑和 diff 时，渲染进程内存会涨。已经发过一些改进，剩下的还在做。用户报告的是 V8 OOM（Ineffective mark-compacts near heap limit），renderer 退出。帖子：Renderer memory leak。
官方给的两条缓解
- 边跑边接受或拒绝 Agent 的挂起改动，尤其是 Reload 之前。挂起改动会在重载后还原进窗口，员工举例重载后回到约 1.6 GB，马上又没余量。
- 内存接近上限前，命令面板跑 Developer: Reload Window。这会停掉该窗口里还在跑的本地 Agent，先收尾或暂停再重载。
员工还写：argv.json 只认固定字段，js-flags 不是其中之一，写进去会被忽略。要加 V8 堆上限，用命令行 flag，不要改 argv.json。具体 flag 字符串论坛回复没展开，这里不编。
什么会话更容易撞
员工口径是 long Agent sessions that produce a lot of edits and diffs。短问答、Ask 模式少改文件，不是这条的主战场。同一窗口连开几个大重构、diff 面板一直挂着，更接近复现条件。用户还写过 4 天 18 次崩溃、跨两个版本；那是报告者的数字，不是官方统计。
这和 Claude Code 长会话内存是另一条产品。Cursor 这条是 Electron renderer。
不要做的
不要指望 Reload 当「官方修复」。员工说部分增长还在修。不要把未接受的 diff 堆到窗口里再重载。不要在 argv.json 里塞 js-flags 然后当客户端坏了。
需要人离开仍跑完的任务，用 Cloud Agent 或 CLI agent persist，少让同一个 IDE 窗口扛整夜 diff。CLI persist 见同批说明，不要和 Reload 混成一步。
还要给官方什么
论坛回复说报告已转给团队，有进展会再帖。新崩溃附上版本号、是否大量未接受 diff、Reload 后是否立刻又到 1.6 GB 量级。那是员工已经用来判断的信号。