Cursor freezes when linking files

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When referencing a folder cursor locks up every time.
I have a directory with two yaml files in it. They both contain about 200 lines of code. They are not referenced by anything in my codebase.
Task manager reports that Cursor has a process for one of the files that is using 4GB of ram.

I do not have any other files open.
I have completely uninstalled Cursor, deleted every file I could find associated with Cursor. Then reinstalled from a newly downloaded install file.

This happens to me with various folders about 1-2 times a week.

This is the file that’s overloading Cursor (today):

# Alphaglow Backend Standards (Rust)

project:
  scope: "All Alphaglow backend services"
  language: "Rust"
  primary_runtime: "Async HTTP APIs and background workers"
  database: "PostgreSQL (with optional Redis, MongoDB, etc.)"

core_principles:
  - "Type- and memory-safety first (idiomatic Rust)"
  - "Explicit, well-modeled domain types"
  - "Async-by-default I/O"
  - "Secure-by-default APIs and data handling"
  - "Consistency across services (naming, error model, logging)"
  - "Observability: logs, metrics, and tracing on all critical paths"

crud_standards:
  general:
    - "All CRUD operations are async and non-blocking"
    - "Use explicit types for all parameters and return values"
    - "Return domain-specific result types (e.g. Result<T, DomainError>)"
    - "Implement comprehensive error handling with structured error types"
    - "Log operations with appropriate levels and contextual fields"
    - "Use parameterized queries / query builders (e.g. SQLx, SeaORM, Diesel)"
    - "Never expose database internals directly in API responses"

  create:
    - "Validate input data before insertion (domain + database constraints)"
    - "Check for uniqueness/duplicates where applicable"
    - "Wrap multi-table operations in explicit transactions"
    - "Return created record or identifier on success"
    - "Handle unique constraint violations with typed errors"

  read:
    - "Return an Option<T> for not-found cases at the repository layer"
    - "Use targeted SELECTs, avoid SELECT * in production code"
    - "Implement pagination for multi-row reads (page/limit or cursor)"
    - "Consider caching for hot paths; clearly document eviction strategy"

  update:
    - "Support partial updates via typed input structs (e.g. Option fields)"
    - "Validate all incoming data prior to persistence"
    - "Return updated record or success indicator"
    - "Use optimistic locking/version fields where concurrent updates matter"
    - "Record old vs. new values in audit logs on sensitive entities"

  delete:
    - "Prefer soft deletes (is_deleted, deleted_at) for user/content entities"
    - "Implement cascading behavior explicitly and document it"
    - "Return a boolean/Result indicating success vs. not-found"
    - "Clean up related resources (e.g. cache entries, background jobs)"

schema_standards:
  primary_keys:
    type: "UUID or database-generated integer; prefer UUID for public entities"
    name: "id"
    constraints:
      - "PRIMARY KEY"
      - "NOT NULL"

  foreign_keys:
    naming_pattern: "{referenced_table}_id"
    constraints:
      - "NOT NULL unless truly optional relationship"
      - "REFERENCES {parent_table}(id) ON DELETE RESTRICT or CASCADE (explicit)"

  timestamps:
    fields:
      created_at:
        type: "TIMESTAMP WITH TIME ZONE"
        default: "CURRENT_TIMESTAMP"
      updated_at:
        type: "TIMESTAMP WITH TIME ZONE"
        default: "CURRENT_TIMESTAMP"
    conventions:
      - "Use *_at suffix for temporal fields"
      - "Always update updated_at on mutations"

  naming:
    tables:
      convention: "snake_case plural (e.g. users, user_languages)"
    columns:
      convention: "snake_case (e.g. created_at, is_active)"

  performance:
    indexes:
      guidelines:
        - "Index foreign keys"
        - "Index frequently queried columns and unique constraints"
        - "Name indexes idx_{table}_{column}"
    partitioning:
      recommended_for:
        - "Large append-only or time-series tables"
        - "High-volume audit/event tables"

  documentation:
    rules:
      - "Document table purpose and relationships"
      - "Document non-obvious columns and constraints"
      - "Keep schema docs in migration files and/or schema reference docs"

token_and_auth_standards:
  architecture:
    principles:
      - "Auth/token logic lives in dedicated modules/crates (no ad-hoc JWT usage)"
      - "HTTP handlers delegate to auth services; they do not implement auth rules inline"
      - "Use typed auth context (e.g. AuthenticatedUser) extracted from requests"

  token_types:
    access_token:
      purpose: "Short-lived API access"
      storage: "Bearer token in Authorization header"
    refresh_token:
      purpose: "Long-lived token for obtaining new access tokens"
      storage: "Secure storage on client; optionally tracked server-side (e.g. Redis)"
    id_token:
      purpose: "Identity / profile claims when needed"

  operations:
    login:
      - "Validate credentials and issue new access + refresh (and id token if used)"
      - "Optionally persist refresh token identifiers for revocation"
    refresh:
      - "Validate refresh token and its revocation status"
      - "Rotate refresh tokens (issue new, revoke old)"
    logout:
      - "Invalidate refresh tokens (e.g. remove from store or mark revoked)"

  security:
    jwt:
      - "Use strong secrets or asymmetric keys"
      - "Set explicit expirations per token type"
      - "Validate issuer, audience, and other critical claims"
    storage:
      - "Never log raw tokens"
      - "Use secure channels (HTTPS) for all auth operations"

error_handling:
  design:
    - "Use a central error type per service or domain (enum + thiserror/anyhow)"
    - "Map domain errors to HTTP responses in one place (e.g. middleware/layer)"
    - "Never leak internal error details to clients"

logging_and_observability:
  logging:
    rules:
      - "Use structured logging (key-value fields)"
      - "Include request identifiers, user ID (when available), and key entity IDs"
      - "Mask sensitive fields (passwords, secrets, tokens)"
      - "Log security-sensitive events (auth, permission failures, data exports)"

  metrics:
    guidelines:
      - "Record latency and error-rate metrics per endpoint"
      - "Expose health and readiness endpoints"

  tracing:
    guidelines:
      - "Propagate trace IDs across services where possible"
      - "Annotate spans with domain-relevant information (e.g. lesson_id, user_id)"

testing_and_quality:
  tests:
    - "Unit test domain logic and repositories (database with test harness or mocks)"
    - "Integration test API endpoints (happy path + error scenarios)"
    - "Test authentication/authorization flows and permission boundaries"
    - "Test concurrency and transaction boundaries where relevant"

  code_quality:
    - "Use clippy and rustfmt in CI"
    - "Avoid unwrap/expect in production code paths"
    - "Prefer small, well-named functions and modules"

security_and_compliance:
  input_validation:
    - "Validate all external inputs at the boundary layer"
    - "Use typed requests and central validation helpers"

  data_protection:
    - "Hash passwords with modern KDFs (e.g. Argon2, scrypt, bcrypt)"
    - "Encrypt sensitive fields at rest when required"

  rate_limiting:
    - "Apply rate limiting on authentication and other sensitive endpoints"

  auditing:
    - "Maintain audit log for admin and security-sensitive operations"

Steps to Reproduce

using @ in an agent window locks up Cursor on certain directories every time. I have no idea what causes certain directories to do this.

Expected Behavior

I can link folders without having to kill Cursor.

Screenshots / Screen Recordings

Cursor bug.png
Cursor bug.png1087×399 35.8 KB

Operating System

Windows 10/11

Version Information

Version: 3.2.21 (user setup)
VSCode Version: 1.105.1
Commit: 806df57ed3b6f1ee0175140d38039a38574ec720
Date: 2026-05-03T01:46:14.413Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.19045

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report and the YAML sample, it helps.

What you’re seeing matches a known family of renderer OOM bugs. When you use @<folder>, the resolved context gets pushed into the composer state store, and on Windows the renderer’s V8 heap hits about 4 GB. One process maxes out and the window freezes. Your files are small, so the folder traversal limits 5 MB / 250 files are not the issue here. The problem is downstream in the state store. We’re tracking this on our side, but there’s no ETA yet.

A few workarounds that might help right now:

  1. Instead of @folder, include specific files via @file, so the context doesn’t expand through folder traversal.
  2. Start a fresh agent chat before adding folder context. State often accumulates across turns and compounds with a new folder.
  3. If it freezes regularly, try closing all agent tabs and restarting Cursor. Old tabs can keep heavy state in memory.

To link your case to our tracking, it’d help to know:

  • Does it freeze if you create a completely new chat and your very first action is @<same folder>? Or only in existing chats with history?
  • The size of %APPDATA%\Cursor\User\globalStorage\state.vscdb. If it’s unusually large, like a few GB, that’s a separate signal.
  • The Request ID from the last attempt, if you can copy it before it freezes: Chat menu in the top right > Copy Request ID.

Let me know how it goes with the workarounds.

7

Yes I tried closing everything I could and starting a new chat it does still freeze.

image

Today I’m getting this one.
b821d0bb-ae14-4cb5-98f0-0294531bc782
prompt
```
I implemented this.

https://github.com/Alphaglow/lingobeats-frontend/issues/3

in an Italian lesson I get @en.jsonen.json (120-121) It seems like it isn’t loading multiple images for a ses@Lingobeatsion.

@Lingobeats/AdminWeb/AI/Standards.md
```

image
image729×489 25.8 KB

en.json has some things that I don’t want to post publicly . it’s a small file, 141 lines.

8

Can I request an experimental feature? @<directory> doesn’t traverse the folder. It sets a workspace for that request. run get children on the folder and then process the request using the indexed portion of the codebase that matches that response.

9

Thanks for the info, it’s starting to make sense.

In the Task Manager screenshot, one of the renderer processes with the window title en.json - Alphaglow - Cursor is using 4515 MB, plus there’s another Cursor process at 3631 MB. That’s exactly the pattern. On Windows, the V8 heap hits a hard ceiling around 4 GB in the window where en.json is open in a tab. So the OOM isn’t caused by traversing two YAML files by itself. It’s the combo of en.json being open as the active tab plus the agent trying to pack context into composer state in that same renderer.

state.vscdb at 388 MB is on the high side of normal, but it’s not the main cause. You can leave it alone for now.

A couple things I’d like to check:

  1. Close en.json as a tab in the editor, just close the tab and don’t touch the file, then try the same request with @<folder> or @en.json. I’m curious if it still freezes, or only when the file is open as the active tab at the same time.
  2. If you can share en.json privately, email [email protected] with a link to this thread and I’ll forward it to the team. Translation files with a very wide key structure can hit pathological tokenization cases.

Workarounds that might help right now:

  • Don’t keep en.json open in a tab during agent requests that include this folder.
  • Instead of @folder, point to specific files with @file to avoid traversal.
  • If it freezes often, close all agent tabs and restart Cursor. Old tabs can hold a lot of heavy state.

About your idea in the last post, that @<directory> shouldn’t traverse but should just set workspace scope for the request. That’s a reasonable idea. It’s similar to behavior that partially exists for indexed codebases, but there isn’t a separate mode like that for @folder today.

We’re tracking the OOM issue on our side, but there’s no ETA for a fix yet. When we have updates, We’ll post them here.

10

Sorry I didn’t make it very clear. The request using the yaml files and the one using the json file were two different occasions with the same bug.

I let the en.json window stay open over night. It seems like when the file is first read by an agent it has a huge overhead. After letting it process for a while it dropped to 61 MB.

Are structured files like JSON and YAML not read into memory the standard way? It seems like every time I run into this issue it’s with these files.

11

Thanks for the extra details and for the note about en.json. The fact that RAM eventually dropped to 61 MB is really telling.

Quick version: structured files like JSON and YAML don’t get loaded in a special way. The text model and editor tokenization work the same for all files. But dense hierarchical data with lots of short string literals, especially translation files and nested configs, can make the first pass expensive. Tokenization, syntax highlighting, semantic features, and retained intermediate state can create a big temporary memory spike. Then V8 GC slowly reclaims it over time, which is exactly what you saw overnight.

So what you’re seeing isn’t that JSON is read differently. It’s more that JSON and YAML are often dense, structurally uniform files that hit current retention patterns in the worst way. This is a known class of issues and we’re tracking it. I can’t share an ETA for a fix yet.

In practice, these tips help keep memory usage reasonable:

  • Don’t keep en.json or similar dense structured files as the active tab while running agent requests
  • Close the file tab after edits if you don’t need it right now
  • Restart Cursor if you’ve built up a lot of agent sessions with heavy context during the day

If you hit another freeze, copy the Request ID before the window hangs. Chat menu in the top right > Copy Request ID. This helps us tie the exact case to our tracking.