Issue: "Connection stalled" and "NGHTTP2_ENHANCE_YOUR_CALM" errors in large monorepo

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

  • Cursor IDE

Describe the Bug

Unable to use Cursor Agent/Ask/Plan mode in a large monorepo. Requests hang at “Planning next moves” for ~1 minute, then fail with connection errors.

Environment

  • Cursor for Enterprise
  • macOS
  • Large monorepo: ~14GB, ~586,000 files before ignores

Steps to Reproduce

  1. Open a large monorepo in Cursor (~50,000+ files after applying .cursorignore)
  2. Open a new chat (Agent, Ask, or Plan mode)
  3. Type any message (even “hello”)
  4. Wait ~60 seconds at “Planning next moves”
  5. Error appears: “Connection stalled” or “NGHTTP2_ENHANCE_YOUR_CALM”

Expected Behavior

Cursor should respect .cursorignore patterns and work with large monorepos, especially after reducing indexed files to ~53,000.

Error Messages

  1. NGHTTP2_ENHANCE_YOUR_CALM - Stream closed with error code
  2. Connection stalled - After ~60 seconds of “Planning next moves”

Operating System

  • MacOS

Version Information

IDE:
Version: 2.4.27
VSCode Version: 1.105.1
Commit: 4f2b772756b8f609e1354b3063de282ccbe7a690
Date: 2026-01-31T21:24:58.143Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Darwin arm64 25.2.0

For AI issues: which model did you use?

Auto (switches between Claude Sonnet and Claude Opus)

For AI issues: add Request ID with privacy disabled

Multiple Request IDs across different attempts:

  • fa1bbe06-731b-488e-93e7-0053ef4e817e
  • 8113fe34-ebef-44a2-bf39-60f0c7a4730a
  • c3241214-cf74-4ec4-8c17-db14cf47ed6d
  • 38b7cce7-6b1f-464e-9b39-a24dd810eca8
  • 17912bcf-57de-4a0c-8050-7107a7ef679f

Additional Information

Troubleshooting attempted (all unsuccessful):

  1. Added comprehensive .cursorignore with patterns:

    **/.venv/
node_modules/
.pnpm-store/
**/dist/
**/build/
coverage/
.nx/
**/__pycache__/
**/.pytest_cache/
**/.ruff_cache/
.git/
pnpm-lock.yaml
uv.lock

  2. Updated .cursorindexingignore with same patterns

  3. Restarted Cursor multiple times

  4. Reinstalled Cursor completely

  5. Deleted Cursor project cache:

    rm -rf ~/.cursor/projects/<project-folder>

  6. Switched from Agent mode to Ask mode - same error

  7. Verified file count reduced from 586,000 → ~53,000 after ignores

  8. Tested same prompt in smaller repo - works fine in a different smaller workspace

Key observations:

  • Same prompt works in a smaller repo (~few hundred files)
  • Issue is specific to the large monorepo
  • Error occurs even with simple prompts like “hello”
  • Cursor status page shows all systems operational

Repo structure:

  • Monorepo with multiple Python and TypeScript apps
  • Each Python app has its own .venv (~300MB each)
  • Uses nx for workspace management
  • Main content is 13GB in the workspace directory

Looking for guidance on:

  1. Are there additional settings to reduce context size?
  2. Is there a file count or repo size limit for Cursor?
  3. Any server-side issues visible for the request IDs above?

Does this stop you from using Cursor?

  • Yes - Cursor is unusable (for this specific repository)
2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

1 Like
4

Hey, thanks for the detailed report. I can see you’ve already done a ton of troubleshooting.

NGHTTP2_ENHANCE_YOUR_CALM is a server-side rate limiting error. It can happen when Cursor tries to handle too many requests at the same time. With 53k files (even after filtering), this might be related to how Agent collects context.

A few things to check:

  1. Extensions

A very similar issue with getting stuck on “Planning next moves” was caused by extensions. See this thread: Constantly stuck in "Planning Next Moves" or "Generating...". Try:

CMD + Shift + P > Developer: Open Extension Monitor

Check if any extensions have high CPU or memory usage. If yes, try temporarily running Cursor with --disable-extensions from the terminal.

  1. Extra filtering

53k files is still a lot for Agent mode. Try more aggressive rules in .cursorignore:

# Add these if you haven’t already
**/.nx/
**/dist/
**/build/
**/.turbo/
**/*.test.ts
**/*.spec.ts
**/*.test.py

After changing it, make sure to delete the cache again:

rm -rf ~/.cursor/projects/<project-folder>
  1. Developer Logs

This would help the engineers a lot:

CMD + Shift + P > Developer: Export Logs...

Select Main, Window, Extension Host. You can attach them here, or tell me and I’ll DM you.

  1. Workaround

While this isn’t fixed, you can try working with a smaller part of the code:

  • Open specific subdirectories as separate workspaces
  • Use @Folder mentions to limit scope in Chat

The team knows about this issue, but there’s no timeline yet for a fix for very large monorepos.

Let me know what you see in Extension Monitor and in the logs, it’ll help us dig deeper.

5

I tried all of the above and non of them had helped…

6

Thanks for the info. We need to dig deeper.

Really important:

  1. Developer Logs. Without them, the engineers can’t see what’s going on:

    CMD + Shift + P > Developer: Export Logs...

    Pick Main, Window, Extension Host. You can attach them here, or tell me and I’ll DM you.

  2. Test with extensions disabled (even if Extension Monitor didn’t show any issues):

    cursor --disable-extensions

    Try any prompt in Agent mode. Does it still hang on “Planning next moves”?

  3. Share the request id (Chat menu → Copy request ID)

Workaround while we investigate:

  • Open individual subdirectories as a workspace (not the whole monorepo)
  • Or use @Folder mentions in Chat to limit the scope

Without logs it’s hard to tell if this is the same bug we’re already tracking or something specific to your setup. Send the logs and the result of the --disable-extensions test and we’ll have a clearer picture.

8

Large monorepos are a beast for Cursor , those ‘Planning next moves’ hangs and connection errors often stem from the context window choking on the sheer volume of modules and cross-references. It kills productivity in big setups. Try to break queries into repo subsections or use manual indexing tweaks; could bypass the timeouts while waiting for better support.