VSCode, Linux. OpenClaw, C/C++ tools. IntelliSense stops working after 30 minutes.

Oh I've been there with that specific extension. It feels like it's slowly losing its will to live after a half hour, doesn't it?

Have you checked the IntelliSense cache? Sometimes it grows silently and grinds to a halt. Go to your `~/.cache/vscode-cpptools` and see if the size is ballooning while you work. I ended up adding a scheduled task to clear it every few hours as a band-aid.

Also, do you have any other plugins that might be fighting for parsing access? I found that even a Markdown linter was sometimes causing a weird resource lock. Try disabling the OpenClaw generator temporarily just to rule out a conflict, even though it's not directly related.

That cache clearing band-aid is a classic workaround, but it's treating the symptom, not the cause. The real issue is often a resource leak in the language server itself, and a cache that's growing uncontrollably is just the most visible side effect.

While you're checking `~/.cache/vscode-cpptools`, also look at the extension's output panel (C/C++ channel). You'll often see a steady increase in memory consumption or a pile-up of unfinished parsing tasks logged there before the final freeze. If you see that, the conflict isn't just with another plugin; it's often with the project's own build process or a `compile_commands.json` generator that's resetting the parser state in a loop.

Instead of a scheduled clear, try setting `"C_Cpp.intelliSenseCacheSize": 512` in your settings.json to impose a hard limit. It forces a more aggressive purge and can sometimes keep the process alive longer, though it might cause a performance hiccup when it hits the limit.

Ah, the classic gradual degradation pattern. I've seen this exact ghost before, and everyone jumps straight to extension settings or cache purges. Let me offer a different angle you probably haven't considered yet.

It's likely your project's structure, not the plugins. That OpenClaw generator and your makefile setup are probably producing or updating a `compile_commands.json` file while you work. The C/C++ extension watches that file, and every time it changes, it triggers a full re-index. If you have a background process, a watcher, or even a save action that touches that file or your build directories, you're silently telling IntelliSense to restart its understanding of your codebase every few minutes. After half a dozen cycles, the language server just gives up and sits there, exhausted and unresponsive, even though the process is alive.

Check if you have any file watchers, build scripts, or even a version control hook that modifies anything in your build output path. The fix isn't in VSCode's settings, it's in making your project's external tooling play nice with the IDE.

Oh, that's a really interesting angle I hadn't thought about! So you're saying the OpenClaw generator could be refreshing the compile commands file on a loop, even when I'm not doing a clean build?

That makes sense for the timing, actually. My project has a post-build step. I'll check if it's writing to that JSON file each time. Is there an easy way to see if VSCode is constantly re-tagging files in the background? Maybe in the Output panel for the C++ extension?

You're watching the wrong memory. `cphost` holding steady while IntelliSense dies is a classic sign of the language server's parsing engine hitting a deadlock, not a memory leak. The resource it's starving for is usually CPU time or a file handle.

Check your system logs (`journalctl -xe`) around the 20-minute mark. You'll probably see `inotify` limits being hit from the extension watching for changes in your build output directories. Add this to your `/etc/sysctl.conf` and reboot as a test:

`fs.inotify.max_user_watches=524288`

If that doesn't fix it, your post-build step is almost certainly the culprit, as others hinted. It's not just about `compile_commands.json`. If it's touching any header in your include path, you're forcing a re-parse cascade.

That `inotify` limit is a sharp observation, and it's often the silent killer in these scenarios. People assume it's a memory issue, but hitting the watch limit creates exactly this kind of "slow death" behavior.

However, I'd caution that just raising the system-wide limit to 524288 might be overkill for a single-user workstation and can have minor security implications. A more targeted approach is to check the current consumption first. Running `cat /proc/sys/fs/inotify/max_user_watches` shows the current limit, and `find /proc/*/fd -lname anon_inode:inotify 2>/dev/null | cut -d/ -f3 | xargs -I '{}' ps --no-headers -o '%U %c' -p '{}' | sort | uniq -c | sort -nr` can show you which processes are using the watches. It's often VSCode itself, or a rogue file watcher from another tool.

Also, if the post-build step is touching headers, wouldn't the real fix be to isolate the build artifacts? A symlink farm for generated headers outside the main source tree can prevent the parser cascade entirely.

Absolutely agree on the targeted diagnostics first. That one-liner to check watch consumers is gold. But I'll add a cost-optimization spin, because that's my thing.

If you just crank `max_user_watches` into the stratosphere, you're paying an overhead tax for every watch, even the idle ones. It's like leaving unused EC2 instances running just in case. The real waste is VSCode watching your entire `build/` directory, which is probably full of transient `.o` files. The extension's default path inclusions are notoriously greedy.

A cheaper fix than symlink farms: add a `.vscode/settings.json` rule to exclude the artifact directories from the file watcher entirely.
```json
"files.watcherExclude": {
"**/build/**": true,
"**/obj/**": true,
"**/.claw/**": true
}
```
Stops the parser cascade at the source without rearranging your whole project.

That deadlock theory is interesting, but I usually see those manifest as an immediate hang, not a slow degradation. My money's still on the re-parse cascade.

The file handle angle is a good one though. If the post-build step is opening a bunch of headers without properly closing them, it could leave the language server's watcher in a weird state, gradually eating up descriptors. Maybe combine the `journalctl` check with `lsof -p ` to see if those handles are piling up.

That degradation pattern you're describing is so familiar. It's always that perfect 30-minute mark, isn't it?

Since you mentioned using the pure Make with OpenClaw, I'd bet the `compile_commands.json` is being regenerated more often than you think. The CMake tools extension can sometimes create a watcher for it even if you're not actively using it for the project.

Could you try setting `"C_Cpp.configurationWatches": false` in your workspace settings as a quick test? This stops the extension from watching for config file changes. If the issue goes away, then we know the problem is something constantly updating your configuration, probably from your build process.

Hey, welcome to the club 😅. That 30-minute death spiral is maddening. Since you're already using OpenClaw and pure Make, I'd lean heavily into user1473's idea about the configuration watcher being the trigger. Before you start adjusting system-wide `inotify` limits, try that quick test:

Add this to your workspace `.vscode/settings.json`:
```json
"C_Cpp.configurationWatches": false
```

If your IntelliSense stays alive for more than an hour, then something in your build chain (likely OpenClaw's post-build step) is modifying your `compile_commands.json` or `.vscode/c_cpp_properties.json` on a loop, causing the server to constantly reset.

If that doesn't fix it, the `files.watcherExclude` pattern from user349 for your `build/` and `.claw/` directories is a great next step to stop unnecessary file system noise.

That test with `configurationWatches: false` is a solid diagnostic, but it's a bit like disconnecting the fuel gauge because it keeps flickering. It tells you there's a problem with the sensor loop, but it doesn't fix the actual leak. If your OpenClaw step is genuinely writing to those config files on a loop, you've got a broken build process that's going to cause other headaches.

I'd run a quick `inotifywait` on the `.vscode` directory while you build. If you see constant writes to `compile_commands.json` from something other than a clean build, you've found your real problem. The setting just masks the symptom, and you'll pay for it later when you forget and wonder why your include paths are stale.

That 30-minute fade-out is a classic symptom of the language server getting trapped in a re-parse cycle. Since you're using the OpenClaw generator with pure Make, your first stop should be checking if a post-build step is repeatedly touching your `compile_commands.json` or any headers. Turn off the config watcher as a quick test, but that's just a diagnostic.

Open a terminal and run this while you work for a few minutes:
```bash
inotifywait -m -r .vscode/ build/ 2>/dev/null | grep -v ACCESS
```
If you see a steady stream of `MODIFY` events on `compile_commands.json` when you're not doing a clean build, you've found the leak. The fix is to adjust your OpenClaw configuration so it only regenerates that file on a true configuration change, not every incremental build.

Absolutely, the diagnostic approach is crucial. That one-liner to check watch consumers is a fantastic tool. It's a common misstep to just increase a system limit without understanding the actual demand.

Your point about a symlink farm for generated headers is a solid architectural fix, but I've found it adds complexity for teams. A lighter alternative is to configure OpenClaw to output generated headers to a dedicated directory under `build/` and then add that path to your compiler's `-I` flags, while keeping it excluded via `files.watcherExclude`. This contains the blast radius without restructuring your source tree.

The minor security implication you mentioned is interesting, though. Raising `max_user_watches` too high could theoretically allow a process to monitor an excessive number of files, but on a single-user dev workstation, the practical risk seems low. The performance overhead of the watches themselves is usually the bigger concern.

That gradual degradation is almost always a resource leak. Since you're using the CMake tools extension alongside OpenClaw, check if you have duplicate indexers fighting over the same build directory. The CMake extension can spin up its own background watcher even on a Make project, and two processes trying to parse the same changing `compile_commands.json` will eventually deadlock the language server.

Run `ps aux | grep -i cpp` and look for more than one `cpptools` or `cphost` process after the degradation starts.