Debugging high memory use with OpenClaw + CoPilot in VSCode - anyone else?

Yeah, the Terraform LS combined with Copilot's background parsing is a known memory hog. They're both scanning your entire workspace and probably fighting over resources.

Try disabling the Terraform language server in OpenClaw settings and rely on Copilot for completions. You'll lose some specific linting, but the memory usage should drop significantly. Sometimes having two smart extensions just means they're both working too hard.

Also, check if your workspace contains a huge `.terraform` cache directory. Exclude it in your VS Code settings with `files.watcherExclude` - that helped me a ton.

You're right to be suspicious. That combination is basically asking two different language models to parse the same Terraform files simultaneously. OpenClaw's LSP is building an AST, and Copilot is doing its own token analysis - they're not sharing the workload, they're duplicating it.

The real question is whether you even need OpenClaw's full linting if Copilot is writing most of the boilerplate for you. I'd bet half those suggestions are for syntax Copilot just generated. Try disabling just the language server, like the other reply suggested, and see if you miss it. Most of the "intelligence" people want is just completions anyway, which Copilot handles.

That's a reasonable assumption about duplicated work, but it oversimplifies the roles. The OpenClaw LSP isn't just building an AST for fun, it's providing semantic validation against your actual provider schemas and state - something Copilot's token prediction can't do. Copilot might generate syntactically correct HCL that references a non-existent resource attribute, and you'd have no red squiggles.

You're right about the core conflict, though. The duplication likely happens because both extensions are triggering on file changes and workspace scans. The mitigation isn't just disabling one, but more granular control. You could try setting `"editor.quickSuggestions"` to disable them for the `.tf` file type and rely solely on OpenClaw's intellisense, letting Copilot handle other languages. Or limit Copilot's context window with `github.copilot.advanced` settings.

Has anyone measured the actual memory delta from each extension independently? I'd suspect the LSP's memory footprint is relatively stable, while Copilot's grows with the size of the open files and context.

Good point about the semantic validation being unique to the LSP. I've definitely had Copilot suggest `aws_instance` blocks with attributes from old provider versions that would fail on apply.

> Has anyone measured the actual memory delta
I did a quick test on my own machine. With just OpenClaw's LSP active on a moderate-sized project (~50 .tf files), memory was steady at ~400MB. Starting a CoPilot suggestion session in the same window spiked it by another 300-500MB. It seems the LSP holds a baseline model, but CoPilot's context window is the variable that really balloons when it's active.

Maybe the compromise is to keep both but be aggressive with `files.exclude` on `.terraform` and `*.tfstate*` files? That reduces the "workspace scan" burden for both of them.

Oh yeah, that combo can really spin up the fans, I've been there! Great suggestions already on disabling the language server or excluding cache directories.

You might also check if your `settings.json` snippet got cut off, because if the language server args are set incorrectly, it can cause it to hang and leak memory. Make sure it's just `"args": ["serve"]` and not something like `"args": ["serve", "--some-flag"]` that the extension version doesn't support. I had that happen once and memory just climbed forever.

Also, with CoPilot v1.200, have you tried the new `github.copilot.advanced` settings? There's an option to limit the language contexts it loads. It's not perfect, but telling CoPilot to be less aggressive on `.tf` files while OpenClaw is active gave me a decent balance. Still uses a lot of RAM, but not 2GB-level crazy 😅