[VS Code] Conversation webview renderer holds ~645MB RSS; /compact and closing sessions don't release it

Environment

• Claude Code VS Code extension 2.1.216 (darwin-arm64)
• macOS, 8GB physical RAM
• 4 parallel Claude Code sessions open in VS Code

Observed

• One Code Helper (Renderer) process (a webview renderer) reached ~645MB RSS with ~47% CPU while the window appeared idle.
• Six renderer processes in total used ~1.3GB RSS.
• This memory pressure pushed the machine to ~3.76GB/4GB swap, making the system near-unresponsive.
• /compact reduced the token context in the claude process but did not reduce the renderer RSS. Closing session tabs also did not reliably release the renderer memory.

Questions / requests

1. Is the conversation panel expected to keep this much rendered DOM in the webview for long sessions? Would virtualized rendering (only visible + nearby messages in the DOM) be feasible?
2. Could /compact (or closing a session) explicitly tear down and re-create the webview from the trimmed transcript?
3. If neither is easy, a setting to cap webview memory would help.

Happy to provide more measurements (e.g. renderer RSS vs transcript size across a range of session lengths) if that helps.