Platform: macOS 15 (Apple Silicon), Cursor latest
Heap: --max-old-space-size=8192 set
Every ~7-10 minutes, renderer crashes with:
CodeWindow: renderer process gone (reason: crashed, code: 5)
Root cause visible in renderer.log — OTEL exporter fires every 7-15 seconds,
server returns 400 “Trace spans collection is not enabled for this user”,
but spans are never dropped — they accumulate until renderer OOMs:
OTLPExporterError: Bad Request
{“error”:“Trace spans collection is not enabled for this user”}
Fix needed: drop/reset span queue on repeated 400 responses instead of retrying.
This affects any account where trace span collection is disabled.
Steps to Reproduce
Cursor crashes every 7-9 minutes for the last three weeks. Literally an unused agent window, no typing, crashes. No steps required.
Expected Behavior
Cursor itself analyzed the logs and suggested I post this bug
This is a known issue. The OTEL exporter doesn’t drop spans when the server rejects them with a 400 status code, so they keep piling up until the renderer runs out of memory.
As a workaround, try turning off Privacy Mode in Cursor: Settings > General > Privacy Mode. The “Trace spans collection is not enabled for this user” error likely means the server is rejecting spans because Privacy Mode blocks telemetry collection. Disabling it should let the server accept the spans instead of them building up in memory.
The team is aware of the problem. There’s no timeline for a full fix yet, but your report helps with prioritization. Let me know if turning off Privacy Mode helps.
Cursor suggested: Our fix: Patch OTEL transport → treat 400 as success → spans dropped locally
Thanks for the quick response and the context. Our diagnosis matches. We patched the OTEL transport locally to treat 400 as success (drop spans immediately), which stops the accumulation without turning off Privacy Mode. That’s working. We’d prefer to keep Privacy Mode on since the workspace contains proprietary code. The patch will need to be re-applied after each Cursor update — a proper fix on your end (drop spans on persistent 400s regardless of Privacy Mode) would be the right long-term solution.