Every hour, my editor froze. It took us a while to find out why, and the answer was sitting in our own files.
What we measured
Opening a session pegged Cursor’s extension host (the background engine that runs its add-ons) for a minute. Dragging the new tab into its own window restarted the session, so we paid the startup cost twice. Our prompt hook also added about 3 seconds to every message.
After a reboot we ran the comparison again. Open in New Window started a session in about 17 seconds. Opening a session with the plus button and then dragging it out took about a minute and restarted it. The extension host pegged a core even on a fresh boot, so restarting it was not the fix.
What it was
The freeze traced to the Claude Code session-list build, the step where the extension assembles the list of past sessions. Two things triggered it: an hourly auto-archive sweep and the webview init, which is the extension’s panel loading up. Both ran over 4,270 transcripts, and the Claude extension was re-reading 5.8 GB each time.
So the hourly freeze was ours.
The 18:15 tick
The analysis named the hourly sweep as a trigger. We predicted the freeze would land on the 18:15 tick, and then it did. It was the tick we had named.
We also built one place that measures the PC every minute and judges whether each change helped or hurt. It already shows kernel memory (the part of memory the operating system itself uses) climbing from boot, cause still unknown. That one is open.
AI Skills
Use this lesson with the AI assistant you already use
Cursor froze about every hour, and restarting the extension host did not help because it pegged a core even on a fresh boot. The team traced it to the Claude extension re-reading 5.8 GB across 4,270 transcripts.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Name the Trigger of a Recurring Stall and Predict Its Next Occurrence to Confirm the Diagnosis
SOURCE: dxdev.com/blog/the-hourly-freeze-was-our-own-transcript-sweep
WHAT HAPPENED: Opening a session pegged the extension host for about a minute, and dragging a tab into its own window restarted the session and paid the startup cost twice. After a reboot the team compared two ways of opening a session. Open in New Window took about 17 seconds, while the plus button followed by a drag took about a minute. The analysis tied the freeze to the Claude Code session-list build, which an hourly auto-archive sweep and the webview init both triggered over 4,270 transcripts. The team predicted the 18:15 tick would freeze Cursor, and the freeze landed on that tick. A separate cause, kernel memory climbing from boot, was left open and labeled as unknown.
THE RULE: When a stall recurs on a schedule, name the suspected trigger and the time of its next run, then check whether the stall lands there. Keep causes you cannot yet explain marked as open instead of folding them into the diagnosis.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. For each recurring stall, the written diagnosis names a specific scheduled job or event and a predicted next occurrence time that can be compared against the observed freeze.
2. Before a restart or reboot is called a fix, a comparison on the same machine shows whether the slowdown persists after it, as the pegged core did on a fresh boot here.
3. Causes that have no evidence yet, such as the climbing kernel memory, are recorded as open items and not attributed to the confirmed trigger.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
