Cursor renderer freezes (100% CPU) on markdown ReDoS when rendering GitHub MCP responses

[amonrreal (Alvaro Monrreal)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

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

1. Configure the official GitHub MCP server
2. Open a new Agent chat
3. Ask the agent to review comments on any PR that has CodeRabbit or similar bot comments (they contain badge images and markdown links)
4. Agent calls get_pull_request_comments or get_pull_request_reviews
5. 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 ![badge](img.shields.io/badge/P1-orange) that cause catastrophic backtracking in the link tokenizer.

Workarounds I found

1. 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:%';"
2. Replace the GitHub MCP with a wrapper that sanitizes all text patterns before returning to Cursor — this alone prevents the crash.
3. 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.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the detailed report and root cause analysis.

This is a known bug with ReDoS in the bundled marked.js when rendering MCP responses. The same stack trace RegExp.exec → y.link → u.inlineTokens has already been documented in a few threads, including the main one: Window becomes unresponsive and reloads when MCP tool returns large response (markdown lexer regex hang)

The team is aware, and your report helps with prioritization. There’s no ETA yet.

Your workarounds, especially using a CLI wrapper instead of MCP and sanitizing markdown patterns, are great options for users hitting this.

I’m closing this thread as a duplicate of the main topic. Let me know if you find anything else.