I am experiencing a persistent glitch where the Cursor Agent gets stuck in an infinite loop. It cycles between “summarizing chat context,” “planning next moves,” and “reconnecting,” before eventually crashing with the following error:
Steps I have already tried (which did not fix the issue):
Network protocol change: Switched HTTP Compatibility Mode to HTTP/1.1 in settings and fully restarted Cursor.
Context reset: Opened a brand-new, empty chat session to ensure it isn’t caused by a bloated history.
Steps to Reproduce
Open Cursor on macOS.
Activate the Cursor Agent in the chat panel.
Submit a prompt or let the agent attempt to run.
The agent immediately loops between “summarizing chat context,” “planning next moves,” and “reconnecting.”
After a few moments, the agent crashes completely and displays the Request ID error message. This occurs even in a brand-new, empty chat session.
Expected Behavior
The Cursor Agent should successfully read the local context, outline its steps, stream the AI response without dropping the connection, and complete the requested task without entering an infinite reconnection loop or crashing.
Screenshots / Screen Recordings
Operating System
MacOS
Version Information
IDE:
Version: 3.18.25
CLI:
CLI Version v2026.08.31-4057e58
For AI issues: which model did you use?
Auto/Cursor Grok 4.6
For AI issues: add Request ID with privacy disabled
Request ID: 87ea2957-791a-4e9d-adc4-f065df0491dc
Additional Information
The issue persists regardless of network protocol settings (tried both default and HTTP/1.1 compatibility modes). I am on a standard home Wi-Fi network with no VPNs, custom firewalls, or corporate proxies running, so the stream shouldn’t be getting blocked on my end. Could an engineer please check the server logs for this Request ID?
Hi @Sam_Brause thanks for the detailed report and the request ID, that made this quick to trace.
Your network is fine, so you can stop chasing the HTTP/1.1 setting. The prompt Cursor assembles for each message is about 1.08 million tokens, more than double what the model can accept, so the model rejects it before generating anything. Cursor then tries to compress the conversation to make it fit, retries, gets rejected again, and repeats a few times before giving up. That’s the “Summarizing chat context” / “Planning next moves” / “Reconnecting” cycle you’re seeing.
Compression can’t help because there’s no conversation history to compress: the size is identical on the first message of a new chat, and it was the same across every chat and model you tried today. Something included with every request is enormous. The usual culprits:
Rules files: .cursor/rules/, AGENTS.md, CLAUDE.md, or .cursorrules in the project (or a parent folder), plus User Rules in Cursor Settings > Rules. A single large or generated file here is the most common cause.
MCP servers: Cursor Settings > Tools & MCP. Servers exposing a very large number of tools add all of their definitions to every request. Try disabling them all as a test.
Anything attached to the chat: pinned files or folders, @-mentions of large files or directories, or large pasted content.
Two quick ways to narrow it down:
Open a new chat and click the context usage percentage at the bottom of the input. It shows a breakdown by category (rules, MCP tools, files, conversation); whatever dominates on an empty chat is the culprit.
Open Cursor in an empty folder and send a one-line prompt. If that works, the cause is in the project (project rules, AGENTS.md/CLAUDE.md, or project-level MCP config). If it still fails, it’s user-level (User Rules or global MCP servers).
Once you trim the oversized item, new chats should work immediately. If you get stuck, tell me what the context breakdown shows on an empty chat and I’ll help you pin it down.