[Windows] browser-use agent's Playwright headless Chrome leaks handles/threads into explorer.exe & dwm.exe, freezing the desktop shell

Summary

When the browser-use agent (Playwright-based) runs for an extended session, explorer.exe and dwm.exe accumulate handles/threads/working-set until the Windows desktop shell becomes unresponsive — even though CPU and total RAM usage look completely normal.

Crucially, in-app interactions keep working (e.g. clicking inside Chrome), while all shell-level interactions stall: taskbar hover animations stop, window thumbnails stop appearing, and clicking a taskbar icon takes several seconds to open the window. This points to a shell-layer resource exhaustion rather than a hardware/CPU bottleneck.

Environment

• kimi-code: 0.29.0
• OS: Windows 11 x64 (build 26200)
• Node: v24.15.0
• UI mode: shell
• Plugins: browser-use (/control-browser, /web-gui-tester) installed and used during the session
• Total RAM: 31.3 GB (only ~16.6 GB in use when the freeze occurs — so this is not a RAM exhaustion issue)

Symptoms

The "freeze" is not a hard hang. It manifests as:

1. Taskbar hover animations and window-thumbnail previews stop working — hovering the mouse over a taskbar app icon shows no animation and no thumbnail.
2. Shell interactions lag by several seconds — clicking a taskbar icon to open its window takes a long time to respond.
3. In-app interaction is completely unaffected — any operation performed inside a window (e.g. navigating within Chrome) works normally with no lag.

Because the lag only affects the desktop shell (explorer/dwm message loop, desktop heap) and not application windows themselves, CPU/RAM monitors show nothing wrong — which makes the bug very misleading to diagnose.

Root cause (analysis)

Live process inspection during the freeze shows two shell-layer processes severely bloated, plus a cluster of Playwright headless Chrome processes spawned by the kimi-code browser-use agent:

Live diagnostic snapshot (collected during the freeze)

Collection time (local): 2026-07-30 09:02

explorer.exe / dwm.exe detail (abnormally high vs. healthy baselines):

Process	Handles	Threads	Working Set	Healthy baseline
explorer.exe (PID 29552)	6503	248	360 MB	~1000–2000 / 30–60 / 50–100 MB
dwm.exe (PID 18552)	3698	99	559 MB	~1000 / 20–40 / 50–150 MB

• explorer.exe uptime at capture: ~20.5 hours, accumulated ~52 min CPU time.
• Metrics are monotonically increasing over the session — they never go down until explorer is restarted. This is a cumulative leak, not a random spike.

Playwright headless Chrome cluster spawned by the agent:

• 5 × chrome-headless-shell.exe processes running.
• Parent chain: chrome-headless-shell (PID 43476) ← parent node.exe (PID 22668) ← kimi-code agent.
• Started via Playwright (ms-playwright\chromium_headless_shell-1228), with flags like --remote-debugging-pipe, --no-startup-window, GPU + renderer child processes.

Why this freezes the shell (but not the apps)

Even in --headless mode, the Playwright Chrome GPU process and IPC channels register compositing surfaces and shell hooks with DWM/explorer. Over many open/close cycles these are not fully reclaimed, so explorer's handle/thread tables and DWM's surface list grow without bound. Once explorer's thread count (~150+) and working set (~300 MB+) cross a threshold, the desktop heap / shell message queue saturates → shell interactions stall, while already-rendered application windows (which only depend on DWM compositing, not the explorer shell loop) keep working.

Reproduction

The freeze is deterministic and reproducible, not a random crash. It reliably appears when these conditions are met simultaneously:

1. explorer.exe has been running for a long time (no reboot/logoff) — ~half a day to a full day of heavy use.
2. The browser-use agent is invoked repeatedly, opening/closing pages via Playwright.
3. explorer threads > ~150 and working set > ~300 MB (the bloat threshold).

When all three hold, the shell freezes predictably. Pure chat sessions (no browser agent) do not reproduce it — explorer metrics stay flat.

Suggested mitigation (current workaround)

# 1. Kill the leaked Playwright Chrome (does not affect the user's normal Chrome)
taskkill /F /IM chrome-headless-shell.exe

# 2. Restart explorer to clear the accumulated handles/threads
taskkill /F /IM explorer.exe
# (explorer auto-restarts; or relaunch via Task Manager > Run new task > explorer.exe)

Shell responsiveness returns immediately after these steps.

Expected fix

• Ensure the browser-use agent fully tears down Playwright/chrome-headless-shell child processes (including GPU + renderer children) after each run, rather than leaving them resident.
• Consider not keeping the browser instance resident by default between invocations, or adding a periodic cleanup.
• Long-term: investigate why repeated Playwright sessions leak shell handles/threads into explorer/dwm so the leak is bounded.

Happy to provide more process traces (full parent/child tree, handle-delta sampling over time, GDI object counts) if helpful.

No files or tests are named; start by tracing the browser-use agent's Playwright lifecycle and reproducing repeated open/close sessions on Windows. Done means Playwright and all chrome-headless-shell child processes are fully torn down after runs, with explorer.exe and dwm.exe resource usage no longer growing.