32GB 的 GCP 开发机——经过第三篇的升级和加固之后——又死了。一样的症状：SSH 超时，内核活着，用户态冻结。看门狗抓到了：五个 node 进程各占 2-2.7GB，合计约 13GB。我以为是 Claude Code，结果是 Cursor 远程服务器连续泄漏了 15 个小时。

The 32GB GCP devbox — upgraded and hardened after Part 3 — died again. Same symptom: SSH timeout, kernel alive, userspace frozen. The watchdog caught it: five node processes at 2-2.7GB each, totaling ~13GB. I assumed Claude Code. It was Cursor's remote server leaking memory for 15 hours straight.

GCP 开发机一天死了两次。第一次是 snap 包引发的无限崩溃循环，修完五项加固以为稳了。几小时后又死了——这次是内存管理的问题。Claude Code 两轮诊断、12 项加固、最后连机型都换了。一次关于 VM 运维纵深防御的完整记录。

My GCP devbox died twice in one day. First time: a snap package triggered an infinite crash loop. Applied five fixes, thought it was stable. Hours later it died again — unbounded memory was the real issue. Two rounds of diagnosis, 12 hardening measures, and a machine type swap. A complete field report on VM defense in depth.