# Bug Report: `language_server_macos_arm` Unbounded Memory Consumption on Startup

[ezrab22]

Bug Report: language_server_macos_arm Unbounded Memory Consumption on Startup

Filed by: Ezra (Windsurf Max tier subscriber, $200/mo)
Date: March 25, 2026
Related issues: #285, #289, #63
Windsurf version: 1.9577.43 (Stable, latest as of March 25, 2026)

---

Environment

Spec	Value
Machine	MacBook Pro 18,3 (MKGP3LL/A)
Chip	Apple M1 Pro (8-core: 6P + 2E)
RAM	16 GB
OS	macOS 26.3.1 (Build 25D2128)
Windsurf	1.9577.43 (Stable)
Binary	language_server_macos_arm (Go binary)
Subscription	Max tier ($200/month)

Workspace Details

Metric	Value
Total workspace size	2.4 GB
Python source code	6.4 MB (400 .py files)
Benchmark log files	1.9 GB (297 files, 38 files >10MB, largest 391MB)
Data files	337 MB
.venv	81 MB (numpy, pandas, xarray — modest)
Total files	5,472

Bug Description

language_server_macos_arm consumes 20-34 GB of RSS immediately on startup, on a machine with 16 GB of physical RAM. This happens within 2-3 minutes of opening Windsurf — not gradually over hours. The process renders the entire system unusable by saturating physical memory, forcing macOS into aggressive swap/compression (8+ GB in compressor, billions of swap I/O operations).

This is not a gradual leak. The process balloons from ~500MB to 20+ GB during its initial startup/indexing phase, every single time Windsurf is opened.

The application becomes completely unusable with other processes or in multiples: Cascade chat fails to send messages, the editor becomes unresponsive, and other applications on the system are affected.

Observed Memory Timeline (Fresh System Reboot)

All measurements taken on March 25, 2026, starting from a cold macOS reboot:

Time	Event	language_server RSS	System State
11:10	Fresh macOS reboot, opened Windsurf	—	15GB used, 121MB free
11:10 +2min	language_server spawned	15 GB + 14 GB (two processes)	Load avg: 216, 0.25% CPU idle
11:14	Processes merged to one	12 GB	Compressor: 8.5 GB
11:16	Continuing to grow	12 GB	Load avg: 16, settling
11:20	After database deletion + .codeiumignore	23 GB	15 GB used, 81 MB free
11:24	After maxMemory setting attempt	20 GB	15 GB used, 133 MB free
11:31	2.5 min after restart	4.7 GB → 27 GB	15 GB used, 83 MB free, 6.3 GB compressor

Key observation: At 11:31, the process was 4.7 GB after 2.5 minutes of uptime. Within 15 seconds of measuring, it had already climbed to 27 GB. Growth rate is approximately 10+ GB per minute during startup.

Process Details

Full command line of the offending process:

/Applications/Windsurf.app/Contents/Resources/app/extensions/windsurf/bin/language_server_macos_arm \
  --api_server_url https://server.self-serve.windsurf.com \
  --run_child \
  --enable_lsp \
  --extension_server_port 50434 \
  --ide_name windsurf \
  --random_port \
  --inference_api_server_url https://inference.codeium.com \
  --database_dir /Users/ezra/.codeium/windsurf/database/9c0694567290725d9dcba14ade58e297 \
  --enable_index_service \
  --enable_local_search \
  --search_max_workspace_file_count 5000 \
  --indexed_files_retention_period_days 30 \
  --workspace_id file_Users_ezra_Desktop_Cerebell_20V2 \
  --sentry_telemetry \
  --sentry_environment stable \
  --codeium_dir .codeium/windsurf \
  --extensions_dir /Users/ezra/.windsurf/extensions \
  --parent_pipe_path /var/folders/zr/5g2yszyj59b16mr3pn3zr97h0000gn/T/server_14fe3070f6090210 \
  --windsurf_version 1.9577.43 \
  --stdin_initial_metadata

Error Messages in Windsurf

Repeatedly observed in the Output panel:

[Info  - 10:29:49 AM] Connection to server got closed. Server will restart.
true
[Error - 10:29:49 AM] windsurf client: couldn't create connection to server.
Error: connect ECONNREFUSED 127.0.0.1:62350
	at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16)
[Error - 10:29:49 AM] Restarting server failed
Error: connect ECONNREFUSED 127.0.0.1:62350
	at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16)

Everything We Tried (None Worked)

1. Full macOS reboot

Result: Language server immediately ballooned to 29 GB (15 GB + 14 GB across two processes) within 2 minutes of opening Windsurf. Not a stale memory state issue.

2. Deleted stale Codeium index database

The database at ~/.codeium/windsurf/database/9c0694567290725d9dcba14ade58e297/ contained a single 2.4 GB SQLite file (embedding_database.sqlite) last modified August 29, 2025 — 7 months stale. Deleted it to force a clean rebuild.
Result: Language server ballooned to 23 GB on next startup. No improvement.

3. Added .codeiumignore file

Created .codeiumignore excluding benchmark_results/, data/, .venv/, *.log, and other non-source directories (1.9 GB of content excluded).
Result: Language server ballooned to 23 GB. The ignore file had no effect on startup memory.

4. pyrightconfig.json with exclude patterns

Created config to limit Python analysis to source directories only.
Result: No effect — the memory consumer is language_server_macos_arm, not Pyright/Pylance.

5. .vscode/settings.json — python.analysis.exclude, files.watcherExclude

Added comprehensive exclusion patterns for the VS Code file watcher and Python analysis engine.
Result: No effect on the Codeium language server process.

6. "codeium.languageServer.maxMemory": 4096 setting

Added to .vscode/settings.json per community suggestions.
Result: Completely ignored. Language server hit 20 GB immediately.

7. Watchdog script (kill -9 when RSS > 4 GB)

Automated script to kill the language server when it exceeds 4 GB, relying on Windsurf's auto-restart.
Result: The process balloons so fast on startup that it exceeds the threshold within seconds of being restarted. The watchdog enters a kill/restart loop every few seconds, making Windsurf completely unusable (Cascade can't send messages, constant "Connection to server got closed" errors).

Impact

• System completely unusable when Windsurf is open — 83 MB of 16 GB free, everything swapping
• Cannot run other development tools alongside Windsurf (Ollama, Python processes, Firefox)
• Paying $200/month for Max tier and cannot use the product as needed
• No workaround exists — every community-suggested fix has been tried and failed

What This Is Not

• Not a gradual leak — this is an immediate startup balloon, not the hours-long growth pattern in issue language_server_linux_x64 memory leak causes system OOM on Remote SSH (60GB+ RSS) #285
• Not workspace-specific — 6.4 MB of Python source should not cause 27 GB of memory usage under any circumstances
• Not an OS issue — macOS 26.3.1 is current; the OS is correctly managing memory pressure from an out-of-control process
• Not a hardware issue — 16 GB is standard for development; the language server consuming 2x total physical RAM is the problem
• Not caused by other processes — every other process on the system behaves normally (Windsurf Helpers: 200-700 MB, Electron: ~100 MB)

Expected Behavior

language_server_macos_arm should have bounded memory usage proportional to workspace size. For a 6.4 MB source tree, RSS should be in the hundreds of megabytes, not tens of gigabytes.

Suggested Investigation

1. The Go binary may have unbounded buffer/cache allocation during initial workspace indexing
2. The --enable_index_service + --enable_local_search flags may trigger a code path that loads all workspace files into memory without streaming
3. The --search_max_workspace_file_count 5000 limit doesn't appear to cap memory — our workspace has 5,472 files (just over the limit), which may trigger an edge case
4. The binary should respect .codeiumignore during indexing to avoid processing multi-hundred-MB log files
5. The codeium.languageServer.maxMemory setting appears to be ignored — the binary needs an actual memory cap (e.g., via Go's GOMEMLIMIT or similar)

Reproduction

1. MacBook Pro M1 Pro, 16 GB RAM, macOS 26.3.1
2. Install Windsurf 1.9577.43 (Stable)
3. Open a workspace with ~5,000 files including large log files (>10 MB each)
4. Observe language_server_macos_arm via top -o rsize — it will exceed 20 GB within 2-3 minutes
5. System becomes unusable