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:

=> 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