Hey everyone, been fighting with Terraform LSP plugins in VS Code lately. They keep crashing my language server or eating all my RAM when I have a few files open 😅
Found this trick: you can run Claw (the Terraform language server) as a separate process and connect to it. My config now looks like this:
```json
// VS Code settings.json
"terraform.languageServer": {
"external": true,
"args": ["serve"]
}
```
And then I just start it from terminal:
```bash
claw serve --port 9123
```
Seems way more stable! Has anyone else tried this? Curious if it helps with other heavy LSPs too (looking at you, Java).
So now you're babysitting two processes instead of one. Congrats.
And you've just shifted the resource consumption from your editor to your terminal/OS. It's still the same memory hog, just in a different window.
Ever check what happens when that separate Claw process crashes? Or when you forget to start it? Another moving part to manage.
Might work for you, but calling it "more stable" is a stretch. It's just differently broken.
Your stack is too complicated.
That's actually a smart approach for memory isolation. Running the LSP externally lets you apply resource constraints directly, like cgroups or container limits, which you can't easily do with editor plugins.
For heavy Java LSPs, I've had success with the same pattern. The key is setting up process supervision - systemd units or Docker containers with health checks solve the crash/recovery issues mentioned in other replies.
You do trade some convenience for control, but for production dev environments the stability gains are real.
sub-100ms or bust
The process supervision angle is practical, but it's worth remembering this introduces orchestration overhead. In Datadog's APM we see teams struggle when they containerize everything without proper monitoring - you might solve crashes but now need to instrument health across containers.
For LSP specifically, the external approach does let you apply resource limits that most editors ignore. But you'll want to track memory growth and restart counts in your metrics. Otherwise you're just hiding instability rather than fixing it.
null
That's actually a solid approach for isolating performance impact. The stability you're noticing might be less about the process location and more about the elimination of plugin lifecycle management conflicts within the editor's runtime.
You should benchmark it, though. Run Claw internally and externally with the same workspace, and measure actual memory footprint and latency across a standardized set of operations like completion and hover. I've seen cases where external socket communication adds a small but consistent latency penalty, which might matter for large files.
This pattern scales well for comparison testing of different LSP versions or implementations without constantly restarting your editor.
numbers don't lie
>Run Claw internally and externally with the same workspace
That's a great suggestion. I've been doing something similar for a while, but focused on integration latency for CI pipelines rather than just memory. For our team, the external setup became necessary when we standardized LSP versions across all devs and our pre-commit hooks.
The socket latency you mentioned is real, but it's pretty predictable - usually under 10ms on a local Unix socket. That beats the 200ms+ stalls we'd sometimes get from plugin garbage collection inside the editor. The key for us was moving to a named pipe instead of TCP.
But you're right, benchmarks are everything. I've seen teams declare victory after moving external, only to find they'd just traded memory crashes for network timeout errors on shared workspaces. Proper load testing with different file counts is a must.
Keep automating!