WebView2 process leak on Windows: 25 msedgewebview2 children spawned via Python multiprocessing, ~30 GB RAM

[ptrcao]

Summary

On Windows 11, running Serena MCP under Claude Code causes a large number of msedgewebview2.exe subprocesses to be spawned via Python multiprocessing workers. These accumulate without being released, consuming tens of GB of RAM. In my case, 25 Python-spawned WebView2 processes were using 29.33 GB before I killed them.

This appears distinct from closed issue #944 (which was about in-process Python cache memory and fixed via PR#944). Here the memory is consumed by external msedgewebview2.exe child processes spawned transitively from Serena's Python process, each with its own EBWebView user-data-dir in %TEMP%.

Environment

• OS: Windows 11 Pro, build 10.0.26200
• Python: 3.11.4 (C:\Users\<user>\AppData\Local\Programs\Python\Python311\python.exe)
• WebView2 Runtime: 146.0.3856.97 (children use 146.0.3856.84)
• MCP client: Claude Code (context: claude-code)
• Install: uvx (via uv cache: C:\Users\<user>\AppData\Local\uv\cache\archive-v0\XiIKL63yuOe4aks2GEraP\Scripts\serena.exe)
• Launch command: serena.exe start-mcp-server --context claude-code --project-from-cwd

Evidence

Process tree (before kill)

python.exe (PID 62316, Serena root)  ← serena.exe start-mcp-server --context claude-code --project-from-cwd
└── python.exe (PID 56608)  ← multiprocessing.spawn worker (--multiprocessing-fork)
    └── msedgewebview2.exe (PID 57508, root WebView2 host)
        └── msedgewebview2.exe × 24 (render/GPU/utility children)

Root WebView2 host cmdline:

"C:\Program Files (x86)\Microsoft\EdgeWebView\Application\146.0.3856.84\msedgewebview2.exe"
  --embedded-browser-webview=1
  --webview-exe-name=python.exe
  --webview-exe-version=3.11.4
  --user-data-dir="C:\Users\<user>\AppData\Local\Temp\tmp9egdon_4\EBWebView"
  --noerrdialogs
  --embedded-browser-webview-dpi-awareness=1
  --allow-file-access-from-files
  --disable-features=ElasticOverscroll
  --mojo-named-platform-channel-pipe=56608.62956.8454838954105898844
  /pfhostedapp:b591bec3b542afa3c100ae7c5dfb56b2625711eb

The --embedded-browser-webview=1 + --webview-exe-name=python.exe flags indicate a Python library is instantiating a WebView2 control (likely pywebview with EdgeChromium backend, or equivalent). Each multiprocessing worker creates its own fresh WebView2 with a unique tmpXXXX/EBWebView user-data-dir.

Memory accounting

Grouping all msedgewebview2.exe on the system by parent process:

Parent	Count	Total MB
msedgewebview2 (all Python-spawned)	25	29,866
python	5	207.8
SearchHost	1	62.8
Acrobat	1	22.1
WhatsApp.Root	1	21.8

Resolving the msedgewebview2-parented ones up the tree: all 25 grandparent to python.exe running multiprocessing.spawn which in turn is a child of the Serena root process.

Leaked temp data dirs

%TEMP% contains 13 orphaned tmpXXXX/EBWebView directories — user-data-dirs that were never cleaned up on worker exit.

Reproduction

1. Windows 11 with Claude Code installed
2. Serena MCP configured as an MCP server for Claude Code (standard claude-code context, --project-from-cwd)
3. Use Claude Code normally against a project for some time
4. Observe msedgewebview2.exe process count and memory growing steadily

I have not yet isolated which Serena code path / dependency is creating the WebView2 instances. The multiprocessing.spawn pattern suggests a worker pool where each worker, on startup, imports a module that instantiates a WebView2 (possibly related to the dashboard, documentation preview, or an LSP/indexing dependency that pulls in pywebview or similar on Windows).

Mitigation (surgical kill)

PowerShell one-liner to kill only Python-spawned WebView2 processes while leaving other apps' WebView2 usage untouched:

Get-Process msedgewebview2 | Where-Object { (Get-CimInstance Win32_Process -Filter "ProcessId=$($_.Id)").CommandLine -like '*webview-exe-name=python*' } | Stop-Process -Force

Confirmed this recovers the full ~30 GB without killing the Serena MCP session or other WebView2-using apps (Outlook, Acrobat, WhatsApp, SearchHost, etc.).

Ask

• Can maintainers identify which Serena dependency / code path is instantiating WebView2 via a multiprocessing worker pool on Windows?
• Whatever it is, the user-data-dir cleanup (tmpXXXX/EBWebView) and worker lifecycle clearly aren't releasing the WebView2 subprocesses.
• Happy to provide logs (~/.serena/logs), run with log_level: debug, or test a fix branch.

---

Filed with gh — I'm happy to add any further diagnostics on request.

[ptrcao]

Root cause identified

After digging into the installed Serena package (serena-agent 0.1.4, installed via uvx) I traced the exact code path:

The leak path

1. serena/agent.py:380 — during SerenaAgent.__init__, when web_dashboard=True (default), it calls self._start_dashboard_viewer(minimized=not self.serena_config.web_dashboard_open_on_launch)

2. serena/agent.py:551 — _start_dashboard_viewer spawns a daemon multiprocessing subprocess:

   process = multiprocessing.Process(
       target=self._start_dashboard_viewer_process_function,
       args=(url, minimized),
       daemon=True,
   )
   process.start()

3. serena/agent.py:524 — target function constructs SerenaDashboardViewer(url, start_minimized=minimized).run()

4. serena/dashboard.py:733-753 — .run() calls:

   window = webview.create_window(self.title, self.url, ...)
   webview.start(_start_callback, icon=icon_path)

5. pywebview on Windows uses the EdgeChromium backend (webview/platforms/edgechromium.py) which instantiates a WebView2 control → spawns ~6 msedgewebview2.exe processes (root + render + GPU + network + utility + crashpad) with a fresh tmpXXXX/EBWebView user-data-dir in %TEMP%.

Why it accumulates to ~30 GB

daemon=True on the multiprocessing Process only guarantees cleanup when the Serena parent Python process exits. It does not clean up when a new viewer subprocess is spawned. So if SerenaAgent is instantiated more than once within a single Serena MCP server process (project switch, re-init, reconnect, etc.), each instantiation spawns a fresh pywebview/WebView2 subprocess tree and the prior one is never terminated — just orphaned and held by the still-alive parent.

In my case I saw 5 orphaned viewer subprocesses × ~6 WebView2 children each = ~30 processes consuming 29.33 GB (plus 13 leaked tmpXXXX/EBWebView temp dirs). The 5 viewer instances line up neatly with multiple re-instantiations of SerenaAgent during the session.

Note: mcp.py:285 has the comment "Create an MCP server with process-isolated SerenaAgent to prevent asyncio contamination" — this isolation presumably creates a fresh SerenaAgent per MCP session, which is the multiplier.

User-facing workaround

Users hit by this can disable the WebView2 auto-launch without losing the dashboard itself. Edit ~/.serena/serena_config.yml:

web_dashboard: true               # keep — web server is fine
web_dashboard_open_on_launch: false   # <-- changes minimized behavior, still creates viewer

⚠️ However, setting web_dashboard_open_on_launch: false does not actually prevent the pywebview subprocess from being spawned — it only passes minimized=True to the viewer, which still runs webview.create_window() + webview.start() with hidden=True. The WebView2 subprocesses are still created, just not visible. So the leak persists either way.

The only config-based workaround that truly avoids spawning WebView2 is:

web_dashboard: false

…which also disables the web server. Not ideal.

Suggested fixes

1. Track the viewer subprocess on SerenaAgent and terminate it before spawning a new one, or in a cleanup/close method. Currently the multiprocessing.Process handle is created locally in _start_dashboard_viewer and discarded after .start().

2. Spawn the viewer at most once per Serena MCP server process lifetime (module-level or singleton scope) rather than per-SerenaAgent-instance. The dashboard URL/port is stable for the server, so one viewer window is sufficient.

3. Respect web_dashboard_open_on_launch: false as an actual opt-out of the pywebview window (not just a hidden=True flag). Users on Windows who are fine browsing to http://localhost:24282/dashboard/ themselves could skip the pywebview path entirely — no webview.create_window call, no WebView2 subprocesses.

4. Clean up tmpXXXX/EBWebView user-data-dirs on viewer subprocess exit (I have 13 orphaned ones in %TEMP% from this session alone).

Environment recap

• Serena 0.1.4 via uvx, --context claude-code
• pywebview stack present: pywebview, pythonnet, clr_loader, pystray (all in the uv env)
• Windows 11 Pro 26200, Python 3.11.4, WebView2 Runtime 146.0.3856.97
• User config: web_dashboard: true, web_dashboard_open_on_launch: true (defaults)
• Claude Code as MCP client (likely re-initializing SerenaAgent repeatedly)

---

Disclosure: I won't be actively monitoring this issue. Hopefully this is enough for maintainers to act on without further back-and-forth. If reproduction details are needed, the file/line references above should be sufficient to replay the flow in isolation.

[MischaPanch]

Thanks for the report @ptrcao !

The issue is simpler than the description, the webview processes are generally not cleaned up. Here my status after terminating Serena

I disabled the pywebview dashboard on windows until the memory leak is solved in 98c7572

@opcode81 FYI

[opcode81]

This duplicates #1277. The issue was already resolved on Friday.

• @ptrcao you were clearly running an older version of Serena

  Serena 0.1.4 via uvx

  but then analyzed the code of the new version, in which the issue was already fixed, so your analysis could never work.

• @MischaPanch the WebView2 (msedgewebview2.exe) processes you are seeing have absolutely nothing to do with Serena. This is a core Windows component for displaying web views, and every other Windows app creates an instance; you'll typically have 30 of them as soon as you even start Windows.
  I am sure you'll remember that I informed you when I fixed this (you were sitting next to me). Therefore, I'll revert your commit.