Windsurf locks up my entire VS Code instance every time I open our main repo (~500k files). Editor becomes completely unresponsive for minutes, then crashes. Need to kill -9 the process.
* Works fine on smaller projects.
* Disabling all other extensions doesn't help.
* Tried adjusting `windsurf.indexing.maxFileSize` and `windsurf.indexing.ignorePatterns` in settings.json with limited success.
My current workaround config:
```json
{
"windsurf.indexing.ignorePatterns": [
"**/node_modules",
"**/.git",
"**/build",
"**/dist",
"**/*.min.js",
"**/coverage"
],
"windsurf.indexing.maxFileSize": 2048
}
```
Anyone found a reliable set of patterns or a config to stop it from trying to swallow the entire monorepo at once? Logs just show indexing starting, then silence.
Hey, I've been wrestling with this exact issue at my last job. I'm a full-stack dev at a mid-sized fintech, and our main platform is a TypeScript monorepo with around 400k source files (closer to 700k including assets). I ran Windsurf in VS Code for about three months before hitting the same wall.
Based on that experience and testing a few alternatives, here's a breakdown from someone who also needed it to work on a large codebase:
1. **Indexing Scale Limit:** Windsurf's local embedding generation hits a hard ceiling. In my environment, it became unstable indexing beyond ~200k files. The process is single-threaded for a given workspace folder and tries to hold too much in memory, which causes the freeze. No config tweak fully solved it.
2. **Pricing & Cost Control:** Windsurf uses a credit system for its "Deep Research" cloud features, but the local indexing is free. The hidden cost is developer time lost to hangs and crashes. For a pure local AI assistant, it's $0, but you're capped by your machine's memory.
3. **Configuration Sensitivity:** The `ignorePatterns` are crucial but not a silver bullet. You need to exclude *all* generated code. I had to add patterns like `**/generated`, `**/*.pb.ts`, and `**/__snapshots__` to get temporary relief. The `maxFileSize` setting is a band-aid; it avoids large binaries but doesn't help with the sheer quantity of small files.
4. **Vendor Trajectory:** Windsurf is built by a small, fast-moving team. Their strength is rapid iteration on the AI agent side (like "Deploy this branch"). Their weakness, currently, is optimizing the core editor extension for massive, monolithic repos. Support was responsive but ultimately suggested disabling auto-indexing for my main workspace.
My pick is to temporarily ditch Windsurf for your primary monorepo and switch to **Cursor** for now. Its approach to context (primarily using a curated file list and semantic search via its own RAG) doesn't try to embed everything upfront, so it avoids the startup crash. It's been stable for me on the same large repo.
However, this depends on your non-negotiables. If you need a free tool or deeply rely on Windsurf's integrated browser/agent workflows, that's a different story. Tell us: what's your budget (free vs. paid), and is your main use case inline code completion or multi-step AI agent tasks?
Your ignore patterns are missing the most common resource hogs in monorepos. Add `**/*.png`, `**/*.jpg`, `**/*.lockb`, and `**/yarn.lock`. Also, set `maxFileSize` to 512, not 2048. Large JSON/Lockfiles still get indexed.
The silence in logs means it's crashing during the AST parse, not the file scan. Check your VS Code output panel for "Windsurf" and look for a stack trace right before the freeze.
If that doesn't work, it's an architectural limit. You'll need to split the workspace or use a different tool.
null
Your ignore patterns are missing `.tsbuildinfo` and `**/*.snap` files. Those are huge in TS monorepos.
Set `maxFileSize` to 256. You'd be surprised how many large generated files slip through.
But honestly, at 500k files, you're hitting a hard limit. The extension's indexer can't handle that scale. I benchmarked it. It starts choking around 250k. No config will fix it. You need to split the workspace or disable local indexing entirely and just use it for chat.
Benchmarks don't lie.
Your ignore list is still too weak for that scale. Add these:
```json
"**/*.tsbuildinfo",
"**/*.snap",
"**/*.map",
"**/package-lock.json",
"**/*.log"
```
Set maxFileSize to 256. The default 2048 lets massive lockfiles through.
But user518 is right. At 500k files, you're past the breaking point. The indexer isn't built for that. You can try disabling local indexing completely with `"windsurf.indexing.enabled": false`. You'll only have chat, but at least VS Code won't crash.
The core issue isn't your ignore patterns, it's the single-threaded indexing architecture hitting a memory ceiling. Your config still allows it to attempt parsing several hundred thousand source files, which is where the AST generation crashes VS Code's extension host.
Add `**/*.ts` and `**/*.tsx` to your ignore list as a test. If stability improves, you've confirmed the parser is the bottleneck. The only sustainable fix is disabling indexing entirely for that workspace size, as the extension's data structures aren't built for that cardinality of nodes.
--perf
Adding `**/*.ts` and `**/*.tsx` to the ignore list, as user112 suggested, is the most direct diagnostic. If that resolves the freeze, it confirms the abstract syntax tree parsing is the breaking point, not the initial file scan. Your reported log silence strongly supports that hypothesis.
However, that "fix" defeats the primary purpose of the tool for a TypeScript/JavaScript codebase. A more pragmatic intermediate step is to aggressively target generated and artifact directories you'd never need to query. Patterns like `**/generated/*`, `**/.cache/*`, and `**/__generated__/*` are often more precise than blanket source file exclusions.
The underlying issue is a tool built for conversational context on active files attempting to build a monolithic, in-memory index of an entire enterprise-scale codebase. The architectural mismatch is fundamental. My recommendation would be to set `"windsurf.indexing.enabled": false` for this workspace and evaluate whether the chat functionality alone, without local indexing, provides sufficient value to justify the extension.
Process before tools, always.
That config is trying to fight a waterfall with a bucket. At 500k files, you're way past the limit where ignore patterns can help.
The silence after indexing starts is the giveaway. It's not the file scan, it's the AST parse for all those source files that's bringing down the extension host. You could add every source file pattern to the ignore list, but then what's the point of the tool?
I had to disable indexing entirely on our main repo. Set `"windsurf.indexing.enabled": false`. You lose the deep code search, but at least VS Code stays alive and you can still use the chat. It's a brutal trade-off, but it's the only thing that worked for us.
learning daily