[Bug]Desktop app hangs previewing localhost dev server; uninstall/reinstall silently wipes all session transcripts
Environment
- OS: Windows 11 Home 10.0.26200
- Claude desktop app: 1.28929.0 (MSIX / Microsoft Store install)
Bug 1: Embedded Browser pane hangs the whole app — not localhost-specific
Originally seen while using the Browser pane tools (preview_start/navigate) to check a Next.js dev server on localhost:3000 — the entire desktop app stopped responding (not just that pane), twice, on separate occasions. No Windows Error Reporting event, no Crashpad report, no OOM/resource-exhaustion event in the System log; the app just hung and had to be killed via Task Manager.
Recurred twice more since (see comments for full detail), broadening the repro conditions:
- Once against a live production page (not localhost), triggered by agent-driven Browser-pane tool calls (
screenshot/read_page) under page/DOM weight. - Once during plain manual/interactive navigation through the embedded Browser pane by the human user — no agent tool calls involved.
So this isn't strictly a localhost-dev-server issue or an agent-tool-usage issue — it looks like an underlying instability in the embedded Browser pane's rendering/compositing path. In both later recurrences, screenshot calls immediately before the hang failed with "the Browser pane is not displayed, so the page is not compositing frames," which may be a useful lead.
Bug 2: Uninstalling/reinstalling the app causes real, unrecoverable chat history loss — not just a local-reattachment issue
After the first hang, I uninstalled and reinstalled the desktop app to recover. Afterward, every prior session's local transcript file was gone from local storage, while account/login data survived, so the app still lists old sessions with no data behind them.
I initially assumed this might just be a local-reattachment problem (session content still synced server-side, just not linked to a live process — see comments below for that investigation). That assumption was wrong. Checking claude.ai directly, the same loss/truncation shows up at the account level too: most chats retained only the last day or two of messages, with everything older gone, and a number of chats were erased entirely. This is not confined to local desktop-app state — it reflects actual data loss (or a sync failure producing the same effect) in the account-level chat history.
Bug 3: Missing-session state is mislabeled as "Remote Control disconnected"
Opening one of these now-empty sessions shows a "Remote Control disconnected" message, even though remote control was never used and I was on the same machine throughout. This sent troubleshooting down the wrong path.
Impact
Lost several substantive working conversations with irrecoverable project context — confirmed not recoverable from claude.ai either.
Suggested fixes
- Investigate the embedded Browser pane's rendering/compositing path for the root cause of the whole-app hang — not limited to localhost dev servers or agent tool calls (see
screenshot"not displayed" errors preceding both later recurrences). - Investigate why account-level chat history on claude.ai shows the same truncation/loss as the local desktop app, not just a local-file/process-reattachment problem.
- Warn before uninstall if local session data isn't confirmed backed up/synced anywhere else.
- Distinguish "local session data missing" from "remote control disconnected" in the UI.
3 Comments
Update on Bug 2/3
Further investigation shows this may not be true data loss. One of my affected sessions ("Image sizing and layout..............") still renders its full prior message history in the UI, even though its local transcript file is absent from %APPDATA%\Claude\claude-code-sessions\. That means the displayed content isn't coming from the local file I inspected. It's likely synced server-side to my account, and the local JSON is closer to CLI-process bridging state (which local process owns which session) than the actual transcript.
So the app can't reattach a live, respondable process to these sessions. History displays fine, but sending a new message gets no response, and the error text ("Remote Control disconnected... turn Remote Control back on") is misleading since remote control was never involved. Bug 1 (the Browser-pane hang) and Bug 3 (misleading error message) stand as originally reported; Bug 2 should be read as "can't resume a session after an app reinstall" rather than confirmed permanent deletion of conversation content.
Additional data point on Bug 1: the Browser-pane hang isn't strictly localhost-scoped. It recurred today in Claude Code (non-desktop-terminal session) while navigating a live production page (not localhost) —
screenshotstarted failing with "the Browser pane is not displayed, so the page is not compositing frames," and shortly after, a large accessibility-tree read (~23k chars, a form step with a 250+ option country dropdown) preceded an apparent app-level interruption. Same failure class as the original report, just triggered by page/DOM weight under the Browser pane rather than specifically a localhost dev server. Might broaden the repro conditions worth investigating.No data lost this time — work in progress had already been committed to git before the interruption, so this is just a repro note, not a new incident report.
Consolidated update (issue body edited to match) — two new occurrences since the original report:
Bug 1 recurrence, take 2: happened again in a Claude Code session (not the desktop terminal specifically) while navigating a live production page — not localhost.
screenshotstarted failing with "the Browser pane is not displayed, so the page is not compositing frames," and shortly after, a large accessibility-tree read (~23k chars, a form step with a 250+ option country dropdown) preceded an apparent app-level interruption. No data was lost that time — work in progress had already been committed to git beforehand.Bug 1 recurrence, take 3: happened a third time shortly after, this time during the user's own manual/interactive navigation through the embedded Browser pane — no agent-driven tool calls involved. Same "not displayed / not compositing" screenshot failure preceded it. This rules out the hang being specific to programmatic Browser-pane API usage; plain interactive use triggers it too.
Bug 2 correction: my earlier comment speculated this might just be a local transcript/process-reattachment issue, with content still safe server-side. That turned out to be wrong — checking claude.ai directly shows the same loss pattern at the account level: most chats retain only the last day or two of messages with everything older gone, and several chats are erased entirely. So the loss (or a sync failure with the same effect) isn't confined to local desktop-app state.
Net effect: Bug 1 looks broader than "localhost dev server hangs the app" — likely something in the Browser pane's rendering/compositing path itself. Bug 2 is confirmed real data loss, not a recoverable reattachment problem.