The IDE kernel crashes, and I can’t run scripts because the status suddenly changes to “pending.”
The temporary workaround is to reload the window or restart Cursor entirely. I’ve tried several ways to fix this, such as always updating to the latest version and installing/uninstalling Jupyter extensions, but nothing seems to work. This has been happening for about 2–3 months.
Steps to Reproduce
It happens randomly. You open a Jupyter notebook, and suddenly you can’t run the next cell. You have to interrupt, restart, and reload the window or close Cursor entirely.
Hey, thanks for the report. This is a known class of issues with Jupyter in Cursor, and the team is aware and tracking it.
A few questions to help narrow it down:
Are you running the notebook locally, or connecting over SSH to a remote machine?
What exact Cursor version are you on? Go to Cursor > About Cursor and paste the info from there.
When the crash happens, open Developer Tools with Cmd+Shift+P, then run Developer: Toggle Developer Tools, go to the Console tab, and send any red errors you see.
Also, try these quick checks:
Turn off Cursor Tab: Settings > Tab > Cursor Tab, disable it, restart Cursor, and use the notebook for a while. Tab autocomplete has been linked to Jupyter freezes in similar reports.
Test without extensions: run cursor --disable-extensions in a terminal, open the notebook, and see if the issue still happens.
Seeing console errors is helpful info. There are two patterns:
SQLITE_ERROR: cannot start a transaction within a transaction from AiCodeTracking. This is a known client-side issue.
Illegal value for lineNumber in displayFusedCursorPrediction. This one is specifically Cursor Tab when working with notebooks.
If you’re still seeing displayFusedCursorPrediction errors, it suggests Cursor Tab might have still been active when the crash happened. Can you double-check: Cursor Settings > Tab > Cursor Tab should be turned off. After turning it off, you need a full restart with Cmd+Q and then reopen Cursor, not just Reload Window.
If Tab is definitely off and the issue is still happening, try the next step: run Cursor without extensions:
cursor --disable-extensions
Then use a notebook for a while. This helps confirm whether an extension is triggering the problem.
The team is aware of the Jupyter stability issue, but there’s no fix timeline yet. Your report with logs helps with prioritization.
I’ve already disabled Cursor Tab, but the issue persists. Disabling all extensions isn’t a viable workaround, as data scientists and analysts rely heavily on tools like Jupyter for exploration, analysis, and visualization.
If core extensions such as Jupyter need to be disabled for Cursor to function properly, then it suggests Cursor may not yet be well-suited for data science or BI workflows, and is currently better aligned with CLI-based engineering use cases.
I’ve attached the errors I’m still encountering after turning off Cursor Tab.
Hey, I can see the new console screenshots, thanks for the detailed logs. There are a few issues here, and the main one is RangeError: Maximum call stack size exceeded in the setScrollDimensions / setScrollTop chain. That points to a recursive loop in scroll rendering for notebook cells, and it’s a bug on our side, not an extensions issue.
I totally get your point, disabling Jupyter and data science extensions isn’t a real solution. The --disable-extensions suggestion was just a debugging step to narrow things down, but these logs already show the root cause is in core scroll handling.
A few things that might reduce how often Cursor crashes until we fix it:
If the notebook is large (lots of cells with outputs, especially charts or images), try splitting it into a few smaller files. Scroll rendering breaks more often when the DOM is heavy.
Use Clear All Outputs before saving from time to time. This reduces rendering load.
Try launching with cursor --disable-gpu, it sometimes helps with scroll related bugs.
The team is aware of Jupyter stability issues. I’m adding this specific stack trace with setScrollDimensions to the tracked issue, it’s really helpful for prioritization.
Let me know if reducing notebook size changes the crash frequency at all.
