When an MCP tool call (specifically get_merge_request_diffs from @zereight/mcp-gitlab) returns a large response, the Cursor window becomes unresponsive and reloads. The MCP tool call itself succeeds — the crash happens when Cursor’s chat UI tries to render the response as markdown.
Steps to Reproduce
Configure the @zereight/mcp-gitlab MCP server (or any MCP server that returns large text responses)
In agent mode, trigger a tool call that returns a large diff response (e.g., get_merge_request_diffs for an MR with many changed files)
The tool call completes successfully, but ~20 seconds later the window freezes and reloads
Expected Behavior
Large MCP tool responses should render without crashing the window. Ideally the markdown renderer would handle large text gracefully (truncation, streaming, or lazy rendering).
2026-02-27 10:29:49.162 [error] CodeWindow: detected unresponsive
2026-02-27 10:30:04.169 [error] [uncaught exception in main]: UnresponsiveSampleError: from window with ID 1 belonging to process with pid 1222
2026-02-27 10:29:49.162 [error] CodeWindow: detected unresponsive2026-02-27 10:30:04.169 [error] [uncaught exception in main]: UnresponsiveSampleError: from window with ID 1 belonging to process with pid 1222
main.log — all 14 unresponsive samples show the same stack (markdown regex):
<14>
at RegExp.exec (<anonymous>)
at y.link (workbench.desktop.main.js:780:908)
at u.inlineTokens (workbench.desktop.main.js:794:1416)
at u.lex (workbench.desktop.main.js:781:110)
at u.lex (workbench.desktop.main.js:780:4769)
at De (workbench.desktop.main.js:822:240)
at Object.useMemo (workbench.desktop.main.js:41563:65673)
<14> at RegExp.exec (<anonymous>) at y.link (workbench.desktop.main.js:780:908) at u.inlineTokens (workbench.desktop.main.js:794:1416) at u.lex (workbench.desktop.main.js:781:110) at u.lex (workbench.desktop.main.js:780:4769) at De (workbench.desktop.main.js:822:240) at Object.useMemo (workbench.desktop.main.js:41563:65673)
MCP user-GitLab.log — the tool call succeeded before the crash:
10:29:28.949 Calling tool 'get_merge_request_diffs'
10:29:29.779 Successfully called tool 'get_merge_request_diffs'
10:29:28.949 Calling tool 'get_merge_request_diffs'10:29:29.779 Successfully called tool 'get_merge_request_diffs'
Timeline:
10:29:29 — MCP tool returns successfully
10:29:49 — Window detected as unresponsive (20s later)
The y.link function in the markdown lexer uses RegExp.exec to detect links in inline tokens. When the MCP response is very large (merge request diffs can be tens of thousands of lines), this regex runs on the renderer thread and either hits catastrophic backtracking or simply takes too long, blocking the UI.
Hey, thanks for the detailed report and root cause analysis. The stack traces pointing to RegExp.exec in the markdown lexer make the issue really clear.
It looks like the chat markdown renderer isn’t protected against very large embedded content blocks, so the regex in y.link blocks the renderer thread. I’ll pass this to the team.
As a temporary workaround, if your GitLab MCP server supports it, try limiting the response size for get_merge_request_diffs (some MCP servers support pagination or output truncation). You can also add a rule that tells the agent to request diffs for specific files instead of the whole MR.
The 2.6.x and 2.5.x versions keep crashing and freezing while rendering longer markdown-like responses from tool calls.
Steps to Reproduce
Do query like this: XXX tool: ‘YYY’ - use this tool to get information how to … . Do several queries in parallel with Composer
In 70% after received tool responses (for 4-5 tool calls), the Cursor freeze. You need to wait 1-5min to become responsible and start working again.
Next close Cursor with the chat visible and open it again. It will start with the last project with chat open and here it become unresponsive/freeze for couple of minutes. Then unfreeze
Starting new Chat, again freeze Cursor.
Also:
I ran my prompt on version 2.4.37 — conversation ID: b383d9a8-22ca-4787-95da-41316c86c0b12.
Upgraded to the newest version 2.6.14.
When the cursor restarted with the conversation, it froze.
I have 100% scenario to reproduce the freeze.
Expected Behavior
No freezing, the 2.4.37 version does not have such problems
Operating System
Linux
Version Information
2.5.x, 2.6.x, 2.7 (Nightly)
For AI issues: add Request ID with privacy disabled
Version 2.6.19 Cursor MCP calls are causing % CPU to exceed 100 leading to IDE freeze. No crash logs recorded in Macbook Console logs report. This issue was not present in previous Cursor version. Prompt is not resolved, Tokens are used nevertheless.
Steps to Reproduce
12 available MCP’s (mainly docs: netlify, starwind ui, astro, etc)
Use any agent
agent calls MCP Astro Docs
???
Freeze
Expected Behavior
Cursor freezes and the only option is to Reopen or close: "The window is not responding. You can reopen or close the window or keep waiting. [ Reopen ] [ Close ] [ Keep Waiting ] “Don’t Restore Edits”
CPU Time jumps from minutes of real use to hours. Cursor restarted but when running it jumped hours:
Cursor freezes and becomes unresponsive whenever the Agent uses the GitHub MCP to fetch PR comments or reviews. The renderer process pegs at 100% CPU and never recovers without manually clearing the chat history DB.
Steps to Reproduce
Configure the official GitHub MCP server
Open a new Agent chat
Ask the agent to review comments on any PR that has CodeRabbit or similar bot comments (they contain badge images and markdown links)
Agent calls get_pull_request_comments or get_pull_request_reviews
Cursor becomes unresponsive
Operating System
MacOS
Version Information
Environment:
Cursor 0.46.x (build 2.6.21)
macOS 14
GitHub MCP server github-mcp-server
Additional Information
Stack trace from ~/Library/Application Support/Cursor/logs/*/main.log:
at RegExp.exec ()
at y.link (workbench.desktop.main.js:870:908)
at u.inlineTokens (workbench.desktop.main.js:884:1416)
at u.lex (workbench.desktop.main.js:871:110)
Root cause
ReDoS (Regular Expression Denial of Service) in the y.link regex of the bundled marked.js. GitHub MCP responses contain markdown patterns like text and image badges like  that cause catastrophic backtracking in the link tokenizer.
Workarounds I found
Clear the chat history DB to recover after a freeze: sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb \ "DELETE FROM cursorDiskKV WHERE key LIKE 'agentKv:blob:%';"
Replace the GitHub MCP with a wrapper that sanitizes all text patterns before returning to Cursor — this alone prevents the crash.
Replace the GitHub MCP with a wrapper that calls gh CLI directly instead of the REST API. The agent treats the output the same way it treats
Bash tool output, bypassing the markdown renderer entirely.
The fact that workarounds 2 and 3 both fix the issue confirms the crash is specifically in the inline markdown renderer, not in the MCP
infrastructure or the network layer.
**What triggered it:** The agent fired 6 parallel Discourse MCP calls in one turn — `discourse_filter_topics`, `discourse_search` × 2, `discourse_read_topic` × 3 — all returning full forum post text (link-dense markdown). A `WebFetch` to `www.cursor.com/plugins` was also in the batch; I clicked Allow. The MCP calls had all already started.
07:10:48 [error] CodeWindow: recovered from unresponsive
07:12:10 [error] CodeWindow: renderer process gone (reason: killed, code: 1)
```
10-minute freeze. No “Stopping wakelock” entry — the agent loop never completed. I killed the renderer via Task Manager.
**CPU at kill: 12.5%** (1 of 8 logical cores = 1 core at 100%). Consistent with the `y.link` single-thread regex spin from the stack trace in this thread — not a network wait (which would show ~0%). The parallel burst amplifies it: 6 tool responses rendered simultaneously means more `[text](url)` patterns hitting the regex at once.
**Screenshot** taken after relaunching Cursor following the renderer kill — shows the 6 Discourse MCP calls as they appear in the recovered chat history. The concurrent `WebFetch` to `www.cursor.com/plugins` (pending Allow at the time of the freeze) is absent: the renderer was killed before that call was persisted to the chat log.
**Contributing factors:** System had slept overnight. The retrieval extension host was already logged unresponsive at 06:45 (`ERR_NETWORK_IO_SUSPENDED`). `Developer: Reload Window` after waking from sleep would reset stale hosts and likely reduce exposure.
