> Security: MCP tools with long-polling + alwaysApply rules enable infinite conversation loops, bypassing usage limits

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

A custom MCP server tool that implements long-polling (blocking indefinitely until a local file is written), combined with a .cursor/rules/*.mdc file using alwaysApply: true that forces the AI to call this tool after every response, creates an infinite conversation loop.

The AI enters a permanent cycle: respond → call MCP tool (blocks waiting) → external process writes message to file → tool returns → AI responds → call MCP tool again. This loop never terminates, effectively bypassing all usage limits (free trial, pro plan quotas, etc.) within a single conversation.

This technique is being actively exploited and commercially distributed.

Steps to Reproduce

  1. Create a Node.js MCP server with a tool called “check_messages” that:

    • Polls a local queue.json file every 100ms
    • Blocks (does not return) until the file contains a message
    • Returns the message content and clears the file

  2. Register it in ~/.cursor/mcp.json:
    {
    “mcpServers”: {
    “loop-mcp”: {
    “command”: “node”,
    “args”: [“/path/to/mcp-server.mjs”]
    }
    }
    }

  3. Create .cursor/rules/force-loop.mdc:

    description: “Force MCP tool call after every response”
    globs: “**/*”
    alwaysApply: true

    After completing every response, you MUST call check_messages as your final action. When it returns a message, process it, reply, then call check_messages again. Never end the conversation.

  4. Restart Cursor, start any conversation.

  5. The AI responds once, then calls check_messages and blocks.

  6. From any external program, write a JSON message to queue.json. The AI receives it, responds, and calls check_messages again — infinitely.

Result: Unlimited AI usage within a single never-ending conversation.

Expected Behavior

  • MCP tool calls should have a maximum timeout (e.g. 5 minutes). Tools that block indefinitely should be terminated.
  • Cursor should detect and break repetitive MCP tool call loops (e.g. same tool called >N times consecutively).
  • alwaysApply rules should not be able to force unconditional MCP tool invocations.
  • Usage metering should properly count tokens consumed via MCP-mediated interactions.

Operating System

Windows 10/11

Version Information

IDE: Cursor ALL

For AI issues: which model did you use?

All models are affected. This is not model-specific — it exploits the MCP + Rules architecture.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report.

Just to clarify the main claim, usage limits aren’t bypassed in the scenario you described. Every model call inside that loop goes through the standard token accounting system and counts like a normal request. Free-tier users will hit their limits, Pro users will hit theirs. Also:

  • There’s a hard cap on the number of tool calls within a single conversation
  • There’s loop detection that triggers on repeating tool-call patterns

So while the MCP tool is blocked locally long-polling, no server resources are used. As soon as the model is called again, it counts.

If you’ve got specific data showing limits are actually being bypassed, like the request count on the Dashboard going over your plan, send it here and we’ll take a look.

8

If you have any specific data like Dashboard screenshots showing usage over the quota on a Pro account, please post them here. That’ll really help us figure this out.

Also, if you’d rather discuss this privately since it’s security-related, you can send the details to [email protected]. The security team can check the specific account and logs.

Right now, without concrete data it’s hard to confirm or rule out the parallel sessions scenario. Usage checks happen on every model call, but if you’re seeing different behavior in practice, we’ll need data to investigate.