Investigating Memory Usage
Damn it, less than 20G of memory left.
I couldn’t believe it. I took a look, and holy crap, there were a ton of node processes.
Manual cleanup:
pkill -f "lark-mcp"
I’d already been seeing constant leaks when using its MCP in Paseo, so I disabled this MCP in my opencode and Claude configs. Later I added this MCP in TRAE too, and toggling a project open and closed a few times in TRAE would devour a huge chunk of system memory. Was this MCP written by an intern?
I investigated this once back on 08-28, and here’s what that round concluded:
The root cause is lark-mcp itself, not Paseo / opencode / how it’s launched.
The experiment was decisive: send a real lark-mcp its initialize, then close stdin (simulating the parent process exiting) → the process is still alive 3 seconds later, exitCode stays null the whole time. Counterexample: run the same test raw with the MCP SDK, and it exits the moment stdin closes.
The StdioServerTransport that lark-mcp uses (official MCP SDK 1.29.0) only listens for ‘data’ / ‘error’. It never handles ‘end’ (EOF), and it never calls process.exit() itself.
I was about to fix this bug and send a PR upstream. Then I checked — someone had already hit the same problem, already fixed it and opened a PR, but it’s been sitting there unmerged forever.
Issue #59 (filed 2026-02-09 by YFDmai): the title is literally “Orphan processes not cleaned up when parent (Claude Code) exits”, describing PPID=1 orphans and 32+ leftover processes. Exactly the same problem I ran into. (He also writes “each process ~1.1–1.2 GB virtual memory“.)
Great, so the official project is a total mess.
What they probably mean is: just use their agent in the web UI to do the searching, instead of searching through MCP.
So I just removed lark-mcp from TRAE as well — I barely use that scenario anyway.
I saw someone in Issue #65 say you can use lark cli now and it’s better.
But for developers, is lark-cli really enough for looking up Open Platform dev docs?
I verified it. I wouldn’t call it full coverage — more like a different angle on different use cases, but it can do doc and API lookups just as well. After installing lark-cli, the skill it ships with, ~/.agents/skills/lark-openapi-explorer/SKILL.md, explicitly documents the approach that guides the Agent to make API calls.
The mechanism is that it scrapes the Open Platform’s llms.txt.
Fine, that works as a drop-in substitute — and it’s cleaner.