Window becomes unresponsive and reloads when MCP tool returns large response (markdown lexer regex hang)

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

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

  1. Configure the @zereight/mcp-gitlab MCP server (or any MCP server that returns large text responses)
  2. 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)
  3. 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).

Operating System

MacOS

Version Information

Version: 2.5.26 (Universal)
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z (1 day ago)
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0

For AI issues: which model did you use?

Opus 4.6 Max

Additional Information

Log Evidence

main.log — unresponsive detection:

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)
  • 10:30:04 — UnresponsiveSampleError logged
  • 10:30:39 — Window reloads, extension hosts terminated

Root Cause Analysis

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.

Does this stop you from using Cursor

Yes - Cursor is unusable

1 Like
Cursor freeze, crash while rendering response from tool calls
Cursor freeze, crash while rendering response from tool calls
3

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.

Let me know if you find anything else.

6

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

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

  1. Do query like this: XXX tool: ‘YYY’ - use this tool to get information how to … . Do several queries in parallel with Composer
  2. 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.
  3. 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:

  1. I ran my prompt on version 2.4.37 — conversation ID: b383d9a8-22ca-4787-95da-41316c86c0b12.
  2. 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

b383d9a8-22ca-4787-95da-41316c86c0b12

Additional Information

2.4.37 version works

Does this stop you from using Cursor

Yes - Cursor is unusable

2 Likes