Alright, so I'm on my quarterly tool rotation and decided to give OpenClaw (the open-source LSP thing for Salesforce) a real shot in VSCode, paired with GitHub CoPilot. The promise was solid: offline-compatible Apex/Flow intellisense plus AI autocomplete. Should be a dream for digging through our org's 15-year-old spaghetti code.
The reality? My VSCode instance now idles at 4.2GB of RAM on a fresh restart. It's not a slow creep—it's an immediate, aggressive land grab. The editor becomes noticeably sluggish within 10 minutes, especially when switching between a Lightning Web Component and an Apex class. CoPilot suggestions start arriving about as fast as a postal service in a snowstorm.
Here's the suspect setup:
- **Editor:** VSCode 1.93, Insiders build (but stable behaved the same)
- **OS:** macOS Sonoma 14.5, M2 Pro, 32GB RAM (so it's not the hardware)
- **Core Plugins:**
* OpenClaw (`salesforce.salesforcedoc-vscode`) v0.8.1
* GitHub CoPilot (`GitHub.copilot`) v1.201.0
* Salesforce Extension Pack (basically everything else)
- **Workflow:** Working across two large Salesforce orgs, one with a truly monstrous amount of custom metadata.
What I'm seeing:
* Two separate `node` processes each chewing 1.5GB+.
* The OpenClaw language server seems to re-index on every file switch when CoPilot is active. CoPilot, in turn, appears to be analyzing the entire LSP output.
* Disabling *either* plugin returns memory use to normal (~900MB). The conflict is clear.
Has anyone else tried this particular doomed pairing? I'm looking for:
* Confirmation I'm not hallucinating.
* Any `.vscode/settings.json` tweaks that might have brokered a ceasefire between these two.
* Whether I should just accept that this combo is inherently unstable and go back to the official, slower Salesforce LSP for now.
I really wanted OpenClaw to work—the data portability and offline angle is huge for me—but this memory tax is a non-starter. It's like the plugins are fighting over who gets to own the AST, and my RAM is the battlefield.
Oof, that's rough but honestly not surprising. LSPs plus an LLM agent in the same process is a classic memory pressure cooker. Those two separate node processes you're seeing are likely the OpenClaw language server and Copilot's own background daemon, each loading their own models or indexes.
Have you tried staggering their startup? I had a similar fight with a different LSP and found disabling Copilot until the project index was fully built helped a ton. The initial parsing of that "monstrous amount of custom metadata" is probably where the real clash happens, both tools trying to build their context maps at once.
What does your activity monitor show as the actual high-memory culprit, the LSP node process or the Copilot one? That could point to which extension's settings to tweak first.