A Cline user running the JetBrains plugin reported the standalone cline-core process crashing with an out-of-memory error roughly every 6-7 minutes. The crash diagnostic meant to help debug it was itself the bigger problem: each crash wrote a ~240MB heap snapshot to ~/.cline/heapsnapshots/, and that snapshot contained hundreds of near-duplicate copies of the session's full in-memory state — including the user's provider API key, in plaintext.
What the source says
Per the GitHub issue, filed 2026-10-29: cline-core (JetBrains plugin 2.0.9, core 4.1.26) streams a full serialized copy of its globalState — chat transcript and API key included — to the JetBrains webview on every state change, with no backpressure on the update queue. During a burst of changes, memory grew from an idle ~270MB to several gigabytes in about 100 seconds before the process hit a JavaScript heap OOM (exit code 134).
Maintainer mkondratek confirmed on 2026-11-02 that the OOM shares its root cause with an earlier report, #15031: the queue never drops stale entries when the IDE falls behind. The same maintainer separately acknowledged the plaintext-key exposure the reporter flagged, saying it "is getting its own fix" tracked apart from the OOM bug itself.
What it doesn't establish
No data loss or external exposure is reported. The heap snapshots and the key stayed on the user's own disk, and the process restarted automatically after each crash — this isn't a breach, it's a credential sitting somewhere it shouldn't. As of 2026-11-09, only a telemetry commit had landed; neither the OOM fix nor the key-redaction fix was merged.
Why it matters anyway
Crash diagnostics are usually treated as inert — dump the state, ship it to the bug tracker, move on. This is a reminder that "dump the full in-memory state" and "that state contains a secret" are two decisions that have to be made together, and here they weren't. If you run Cline's JetBrains plugin, it's worth checking ~/.cline/heapsnapshots/ and rotating any key that was active during a crash.
Full scoring breakdown and source: https://www.stupidllm.com/incident/STUPID-2026-0166/


