Desktop startup is blocked by synchronous, eager loading of every open workspace's chat history

Description

Desktop startup is blocked by synchronous, eager loading of every open workspace's chat history

Summary

OpenCode Desktop loads the chat history of all open workspaces synchronously at startup. With a few large-history workspaces open, the sidecar blocks on one CPU core for 1.5–2.5 minutes before the app is usable. The window renders in ~2s, so the user sees a fast UI followed by a long freeze with no explanation. The work is CPU-bound, does no disk I/O during the stall, and scales with total history size.

Environment

• OpenCode Desktop 1.18.31 (packaged), Windows 11
• Several workspaces open as tabs, some with large chat history

Reproduction

1. Open several workspaces with substantial chat history (e.g. two workspaces of ~50–100 MB / 40–80 sessions each).
2. Fully restart Desktop.
3. Window appears in ~2s, but the app is unresponsive for 1.5–2.5 minutes.

Evidence

Window is fast; the sidecar is not (main.log):

app starting
server ready        # ~2s

Sidecar blocks during instance bootstrap (opencode.log), same run:

gap ~91.5s
gap ~59.6s          -> ~151s total before the app is usable

Pure CPU, no disk I/O (per-process sampler, 3s interval):

sidecar (node.mojom.NodeService): 1.1–1.3 cores sustained
  disk reads ≈ 0 MB/s during the entire stall
  RSS grows steadily across the stall (e.g. +~140 MB)

The RSS increase tracks the open workspaces' history size (e.g. ~140 MB extra for two workspaces of ~54 MB + ~92 MB).

Cost scales with open workspaces and their history, not with file counts:

Open workspaces	total history	startup stall
1 small workspace (~9 MB)	~9 MB	~0s
2 large workspaces	~146 MB	~151s
many workspaces	~220 MB	~100–150s

=> roughly ~1 s of blocked CPU per MB of open-workspace chat history.

Ruled out (isolates the cause): file watcher, git prune/gc, the event table, and plugins — none change the stall, and the disk does zero I/O during it. The cost is in reading/processing session/message history, not files.

Root cause

The server eagerly reads and processes the entire history of every open workspace synchronously on the startup path (Server.listen → per-workspace bootstrap). There is no lazy loading and no yielding to the event loop, so the work is O(total history of all open workspaces) and monopolizes a core until it finishes.

Expected

• Only the workspace in view should be initialized at startup; other open workspaces should initialize lazily when selected.
• History loading must not block the startup path or the event loop (async, batched, with backpressure/progress).

Suggested fix

1. Lazy-load per workspace: initialize a workspace's history when it is opened/focused, not at app startup.
2. If eager warm-up is desired, run it asynchronously off the critical path, bounding concurrency and yielding between workspaces so the app stays responsive.
3. Add a work budget / progress indicator so large histories degrade gracefully instead of freezing the app.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response