Hey folks, has anyone else been tracking the discussion on GitHub issue #4521 for the Claw editor? The title says it all: a potential memory leak tied specifically to the markdown preview plugin. I was deep in a long documentation session yesterday and noticed my system monitor spiking like crazy after a couple of hours with the preview pane open on a sizable `.md` file.
I'm on macOS Ventura, running Claw version 0.8.3, and my plugin list is pretty typical for a language model tinkerer:
* Claw Core (bundled)
* Markdown Preview Enhanced 2.7.1
* LSP-langchain 0.4.2
* Vector Database Navigator 1.1.0
* Prompt Snippets Manager 0.9.5
* CodeLLM Integration 1.2.0
What's super interesting—and a bit concerning—is how this might interact with other memory-sensitive plugins, especially ones dealing with embeddings or LLM contexts. The issue thread suggests the leak might be in the rendering engine's cache that never gets purged when you close the preview tab or switch files. A few users reported that disabling the preview stops the memory climb, which points the finger pretty clearly.
I'm curious if anyone in the community has done any side-by-side testing or found workarounds? For instance:
* Does the leak happen with all markdown files, or only those with specific elements (like embedded HTML, large code blocks, or Mermaid diagrams)?
* Has anyone tried pairing it with a memory profiler to see if the leak correlates with specific actions (scrolling, editing, toggling preview states)?
* Are there any known conflicts with language server plugins that also watch markdown files? I'm wondering if the LSP-langchain plugin, which does its own parsing for RAG context, might be doubling up on something.
This feels like one of those sneaky issues that starts as a minor annoyance but could really tank performance during long eval runs or when you have multiple projects open. My usual workflow involves having API docs in markdown open alongside my code, so this is a big deal for me. Would love to compare notes and see if we can pinpoint the trigger!
I haven't tried side-by-side testing yet, but I can confirm the memory climb on Windows too. My workaround has been to just avoid the preview pane when working on long files, which isn't ideal.
Does the issue mention if it's worse with files containing lots of embedded images? I wonder if that's a factor.
Yes, I've been watching that issue closely. Your plugin list is interesting because you've got the Vector Database Navigator and the LSP-langchain plugin. Both could be generating significant background logging that the preview plugin might be inadvertently holding references to, if the leak is in the rendering cache.
I'd be curious to see the audit trails or process monitors from a session. If you have a moment, could you check if there's a correlation between memory jumps and specific operations, like saving the file or scrolling to a section with an embedded data table? Sometimes the leak isn't linear but event-triggered, which would change the troubleshooting approach. The GitHub thread hasn't pinned down the exact trigger yet beyond "keeping the pane open."
Logs don't lie.