[Bug] dsh-client-ui-chat causes renderer main-thread freeze on startup (Windows, 0.2.1-rc.3)

[cpero139]

✅ RESOLVED (2026-10-29): not a DSH bug. The startup freeze is caused by the third-party plugin dsh-purge — three MutationObservers on document.body ({childList:true, subtree:true}) that write DOM inside their own callbacks, creating an endless microtask loop. Guarding those three observe() calls drops renderer CPU from ~119% to ~2%. Disabling ui-chat/ui-conversation only removed the plugin attach target, which is why it looked like a chat-UI bug. Official desktop build is still 0.2.1-rc.3 and no upgrade is needed. See the resolution comment below for evidence, A/B numbers and the workaround.

---

Summary

On Windows, DSH desktop 0.2.1-rc.3 hard-freezes on every startup: the renderer main thread enters a non-interruptible busy loop ~11–22s after launch (single core pegged at 100%, UI unresponsive, process only killable with /F). The loop is triggered by the built-in chat UI (dsh-client-ui-chat / dsh-client-ui-conversation).

Environment

• OS: Windows 10/11 x64 (build 10.0.26100)
• DSH: 0.2.1-rc.3 (installed at D:\ProgramData\DeepSeekHarness)
• Electron: 44.7.0 / Chrome 152.0.7977.130
• Node (host runtime): 24.21.0
• Locale: zh-CN (but reproduced independently of locale settings)

Repro

1. Install DSH 0.2.1-rc.3 on Windows (clean path).
2. Launch DeepSeek Harness.exe.
3. Within ~11–22s the renderer main thread pegs one core at 100% and never yields:
   • Get-Process shows renderer CPU time growing linearly (~80s CPU in 90s wall time).
   • A single renderer thread stays Running with TotalProcessorTime accumulating for the whole process lifetime.
   • CDP Runtime.evaluate times out; Debugger.pause cannot interrupt (native-level busy loop, not plain JS).
   • The window stops responding; the process must be force-killed.

Root-cause localization

• The loop is in the built-in chat UI:
  • Patching - id: ui-chat / ui-conversation ... disabled: true into cordis.patch.yml eliminates the freeze (CPU drops from ~80s to ~1s over 90s), but leaves the app in an "unavailable" state (those are core UI components, so disabling them is not a fix).
  • Re-enabling them reproduces the freeze on every boot.
• The freeze is independent of:
  • User patch configuration (reproduced with cordis.patch.yml removed).
  • User data (reproduced with a fresh --user-data-dir).
  • GPU/software rendering (--disable-gpu --disable-software-rasterizer still freezes).
  • Install layout (reproduced loading from the full app.asar instead of the unpacked resources/app).
• Just before the freeze, DOM grows explosively: document.body.innerHTML jumps from ~1,054 chars / 27 nodes to ~211,510 chars / 999 nodes in under a second, right after api/session/create returns 200. The loop then parks in native layout/rendering (matches a React infinite re-render/scheduler busy loop rather than a JS while).

Diagnostics already performed

• Captured pre-freeze console via CDP (only recurring message before the freeze was ws://127.0.0.1:9230/ingest failing — from dsh-experimental-inspector; disabling that inspector did not fix the freeze, so it is a red herring).
• Confirmed the freeze starts while the UI is still on the "Loading plugins…" boot screen in some runs and right after session creation in others (timing varies, but always within ~22s of launch).
• dsh-client-ui-renderer / dsh-client-ui-chat / dsh-client-ui-conversation are all 0.2.1-rc.3; the freeze persists with all third-party plugins removed.

Impact

DSH desktop is effectively unusable on this machine — it freezes on every launch and must be force-killed. This likely affects other Windows users on 0.2.1-rc.3.

Suggested investigation areas

• dsh-client-ui-chat / dsh-client-ui-conversation React components subscribing to session/projection streams (useSyncExternalStore + slot rendering in dsh-client-ui-renderer) — look for an unstable getSnapshot / infinite store update that drives unbounded re-renders during initial session creation.
• React scheduler busy-loop on Windows under Electron 44 (main-thread freeze not interruptible by Debugger.pause).

Happy to provide a full diagnostics dump (CDP logs, process/thread captures, patch config) or run a debug build on request.

[cpero139]

Update: The official installer only ships 0.2.1-rc.3 — reinstalling from the official package leaves the installed version at 0.2.1-rc.3 (verified from the installed app.asar and exe version), so the startup freeze persists exactly as described. Reinstalling rc.3 does not help.

Could you please publish the Windows installer for 0.2.1-rc.4 or 0.2.2-alpha.2? The nightly update feed (download.deepseek.com/dsh-desk/feeds/win-x64/) currently returns 404, and GitHub Releases contains no installer assets, so Windows users have no way to upgrade. Thanks!

[cpero139]

Follow-up (2026-10-28) — deep-dive into the shipped app.asar: one real ResizeObserver loop found, plus dead ends to skip

I extracted the shipped app.asar and instrumented the running renderer bundle (plugins are served from the asar at dsh-app://app/plugins/??...&rev=<hash>; --enable-logging --log-file captures renderer console). Summary of what helped and what didn't, so you don't repeat the dead ends.

Useful finding — a real ResizeObserver feedback loop (locally fixed, but it is NOT the whole freeze):

• In dsh-client-ui-conversation, observeControlRow (composer model-selector overflow detection) observes the row and every child. measure() first removes the data-model-compact attribute, measures, then toggles it. Because [data-model-compact] hides the model text (--dsh-composer-model-text-display:none), child widths change, the child ResizeObservers re-fire, and the measured needed width oscillates between ~98px and ~784px on a 696px row — an infinite native layout loop.
• A local fix that stops the oscillation: observe only the row and skip when the row width is unchanged (if (width === lastWidth) return;). After the fix the oscillation disappears (one measurement, no re-entry).
• However, the startup freeze persists — the renderer still pegs CPU in a native busy loop even with that loop fixed. So there is a deeper layout/ResizeObserver feedback, likely in dsh-client-ui-chat's fold/spacer management (reclaimBelow / setSpacer).

Dead ends already tested (please don't repeat):

• Overriding dsh-client-ui-chat / dsh-client-ui-conversation / dsh-client-ui-renderer to 0.2.1-rc.4 inside the profile: freeze persists. The rc.4 npm packages do not contain the freeze fix (conversation rc.3→rc.4 is only a tab-tooltip change; chat/renderer are version-bump only).
• CDP Profiler.stop times out during the freeze, so a JS CPU profile cannot be captured.
• --enable-logging shows no JS error before the freeze; the session event feed publishes exactly once (replace, 4 entries) — the loop is not event-driven.

Could you please publish the Windows installer for 0.2.1-rc.4 / 0.2.2-alpha.2? Windows users are stuck on the freezing rc.3 with no upgrade path.

[cpero139]

RESOLVED (2026-10-29) — root cause identified: it is NOT the built-in chat UI

Correction to the report above. The startup freeze is caused by the third-party plugin dsh-purge (its front-end client.js), not by dsh-client-ui-chat / dsh-client-ui-conversation. There is no upstream DSH defect to fix here, and no rc.4 installer is required.

Root cause

dsh-purge registers three MutationObservers on document.body with { childList: true, subtree: true } (v1.1.81, client.js lines 8886 / 8943 / 9008). Their callbacks write DOM back into the page (row.insertBefore/appendChild('.dshp-hero-chip') plus React portal updates). MutationObserver callbacks are microtasks, so mutations created inside a callback are re-queued in the same microtask checkpoint — the event loop never yields back to rendering. Each pass also runs four full-document querySelector calls (including three case-insensitive substring matches such as [class*="hero" i][class*="workspace" i][class*="row" i]) and getComputedStyle on children (forced layout), so a single pass is expensive.

The loop starts when the new-session hero row mounts (5–7 s after app.boot), which matches the ~11–22 s "freeze after launch" timing reported above. If the app is parked on another page (e.g. plugin market) the hero row never mounts and the freeze does not trigger — the same config can look healthy sometimes.

Why it looked like a chat-UI bug

• Disabling ui-chat / ui-conversation most likely removes the hero row that dsh-purge attaches to. ensure() then finds no target to write, so the loop stops. The attach target disappears, not the culprit.
• "All third-party plugins removed" did not actually unmount them: mounting is driven by cordis.patch.yml, not by package.json → dsh.profile.bundles. Deleting the bundle entry alone leaves the plugin mounted (verified by CPU measurement).
• Debugger.enable times out once the loop is running (the main thread no longer services inspector tasks), but the V8-interrupt Debugger.pause still works if the debugger is attached before the loop starts. That is how the stack was captured — repeated samples at the concatenated plugin bundle dsh-app://app/plugins/??..., line 128457: new MutationObserver(() => ensure()) (and sync at 128397). Note Debugger.CallFrame has no scriptId; it is at callFrame.location.scriptId.

Verified A/B (same machine, same session)

• Loop running: renderer ≈105–119 % of one core (165.9 s CPU over ~140 s lifetime, 1145 MB working set); window paints but is unresponsive; survives minimize; zero disk I/O; flat memory → pure microtask/sync loop, not rAF/timer or allocation.
• With the three observe() calls guarded (if (false && obs) ..., keeping the 1 s setInterval fallback so the feature still works): renderer 5 %, then +0.4 s over a 20 s re-sample (2 %); UI fully interactive.
• Update-dependency proof: dsh-purge auto-updated 1.1.79 → 1.1.81, which rewrote client.js and wiped the local guard; the freeze immediately returned at 119 %. Re-applying the guard brought it back to 2 %.

Official version status (re-checked 2026-10-29)

• https://download.deepseek.com/dsh-desk/feeds/win-x64/nightly.yml currently returns 200 and serves 0.2.1-rc.3 (releaseDate: 2026-10-23T08:02:12.038Z, installer 289,415,960 B) — identical to the installed build.
• latest.yml, stable.yml, beta.yml, alpha.yml, preview.yml → 404. npm @deepseek-ai/dsh-desktop → 404 (unpublished).
• The npm UI-component packages (0.2.1-rc.4, 0.2.2-alpha.2) exist but do not contain a fix for this — overriding them inside the profile was already tested above and does not help.
• So Windows users have nothing to upgrade to, but they also do not need an upgrade: the freeze originates in a third-party plugin.

Workaround

Either

1. patch the three sites in ~/.dsh/profiles/desktop/node_modules/dsh-purge/client.js:
   if (obs) obs.observe(document.body, { childList: true, subtree: true }); → if (false && obs) obs.observe(document.body, { childList: true, subtree: true });
   (re-apply after every plugin update, or fold it into a pnpm patch), or
2. pin / remove dsh-purge.

The observeControlRow ResizeObserver oscillation described in the follow-up is a real bug in dsh-client-ui-conversation, but it is separate and not the cause of this freeze.

Suggestion for plugin developers: never observe document.body with subtree: true while writing DOM inside the callback; if you must, coalesce writes into requestAnimationFrame and observe the narrowest container possible.

Marking this resolved.