Windsurf v1.9544.35 — Memory & CPU Regression Analysis
1. Executive Summary
Windsurf version 1.9544.35, released February 5, 2026, introduced a new proprietary binary
(language_server_macos_arm) that aggressively indexes all files in the workspace directory
to provide AI context. On an 8 GB Apple Silicon machine with a 43 GB mixed-content workspace, this process
consumed 4 GB of RAM and 125% CPU, rendering the system nearly unusable.
The same workspace operated without issue on prior Windsurf versions for over a year, including periods when the workspace exceeded 100 GB. The regression correlates exactly with the Feb 5 update.
2. Key Metrics
3. Process Memory Breakdown
Top 10 processes by memory consumption at time of capture:
4. Root Cause Analysis
4.1 The New Binary
The language_server_macos_arm binary is a 168 MB proprietary AI context indexer that shipped with Windsurf v1.9544.35 on February 5, 2026. It continuously indexes all files in the
workspace directory to feed context to the AI assistant (Cascade).
4.2 The Workspace Mismatch
4.3 File Types Being Indexed
| File Type | Size | Useful to AI? | Indexable? |
|---|---|---|---|
| .swift source files | ~13 MB | Yes | Yes |
| .md / .html docs | ~50 MB | Yes | Yes |
| .py / .sh scripts | ~5 MB | Yes | Yes |
| .pcap / .pcapng | ~10 GB | No | No (binary) |
| .gz / .tar.gz | ~12 GB | No | No (compressed) |
| .sqlite / .sqlite-shm | ~8 GB | No | No (binary DB) |
| .pklg (Bluetooth trace) | ~2 GB | No | No (binary) |
| .zip archives | ~1 GB | No | No (compressed) |
5. Timeline
language_server_macos_arm binary (168 MB) deployed to .../windsurf/bin/.language_server_macos_arm consuming 4,039 MB RAM and 125.5% CPU. Total Windsurf footprint: 5.8 GB of 8 GB system RAM..windsurf/settings.json with files.watcherExclude for heavy directories.6. System Impact
6.1 Swap Pressure
6.2 Comparative Impact by Machine Tier
| Machine | Total RAM | Windsurf % | Free After | Impact |
|---|---|---|---|---|
| M1 MacBook (base) | 8 GB | 73% | 116 MB | Unusable |
| M1/M2 (16 GB) | 16 GB | 36% | ~10 GB | Degraded |
| M2/M3 Pro (32 GB) | 32 GB | 18% | ~26 GB | Manageable |
| M3 Max (64 GB) | 64 GB | 9% | ~58 GB | Unnoticeable |
7. Binary Details
| Property | Value |
|---|---|
| Binary name | language_server_macos_arm |
| Size on disk | 168 MB (161 MB file + runtime) |
| Architecture | ARM64 (Apple Silicon native) |
| Install date | February 5, 2026 00:02 |
| Location | .../Windsurf.app/.../windsurf/bin/ |
| Launch args | --api_server_url [redacted] |
| RAM at capture | 4,039 MB |
| CPU at capture | 125.5% (multi-threaded) |
| Companion binary | fd (2.6 MB) — file discovery tool |
The fd binary bundled alongside is a known open-source file finder (MIT licensed, as indicated
by fd.LICENSE). The language_server_macos_arm binary is proprietary to Windsurf
and appears to use fd for workspace file discovery before indexing.
8. Workaround
Creating a .windsurf/settings.json in the workspace root with file watcher exclusions
reduces the indexer's scope:
9. Recommendations for Windsurf Team
The indexer should skip files and directories listed in
.gitignore.
If a file isn't tracked in version control, it's unlikely to be useful for AI context..pcap, .sqlite, .gz, .tar, .zip, .pklg, and other binary formats should be excluded from text indexing automatically.The language server process should have a configurable memory limit (e.g., 512 MB default) and gracefully degrade when approaching it, rather than consuming all available RAM.
Allow users to specify which directories the AI should index, rather than defaulting to the entire workspace root. A
"cascade.indexPaths" setting would solve this.Performance regressions that are invisible on 64 GB machines can be catastrophic on 8 GB machines. QA should include resource-constrained environments.
10. Methodology
Data was collected using standard macOS diagnostic tools: top -l 1 -o mem for process
memory snapshots, ps aux for process details, du -sh for directory sizes,
and ls -la for binary metadata. All PII (usernames, home directory paths, API URLs)
has been redacted from this report. No reverse engineering of the proprietary binary was performed.
