Repository navigation
Slow startup / long loading time every time the OpenCode desktop app is launched (30+ seconds before the UI becomes usable) #41477
Description
Summary
Every time I open the OpenCode desktop application on Windows, it takes a very long time to load before the interface becomes usable. The delay is consistently reproducible on each launch — it is not a one-time cold-start cost. I'm looking for confirmation of the root cause and suggestions to reduce startup latency.
Environment
| Item | Value |
|---|---|
| OS | Windows 11 (win32), PowerShell 5.1 as default shell ("shell": "pwsh") |
| OpenCode config | C:\Users\14540\.config\opencode\opencode.json |
| Model | opencode-go/deepseek-v4-flash |
| LSP | enabled ("lsp": true) |
| Snapshot | disabled ("snapshot": false) |
| Workspace | D:\Code\编程语言学习 (static site, ~28 MB total) |
Startup-related inventory (collected from the machine)
These are the load-bearing items that execute or are scanned on every startup:
1. Skills — 144 skill directories are scanned
~/.config/opencode/skills: 35 skills~/.claude/skills: 33 skills~/.agents/skills: 76 skills (including a large Azure suite)- The global
AGENTS.mdinstructs that the full skill catalog be evaluated on every conversation.
2. Plugins — 4 plugins loaded
opencode-supermemoryopencode-notify@tarquinen/opencode-dcpoh-my-opencode-slim- Plugin dependency footprint:
~/.config/opencode/node_modules≈ 79.8 MB
3. MCP servers — all enabled
oh-my-opencode-slim.jsonsetsmcps: ["*", "!context7"]on the orchestrator preset, meaning every configured MCP server is started at launch (network connections, handshakes, etc.).
4. Global config surface
opencode.jsonwith custom permission rules, LSP enabled, watcher with ignore patterns- Multiple plugin config backups in the same directory (6
oh-my-opencode-slim.json.bak*, 7opencode.json.bak*) — cosmetic, not a load factor, but noted autoUpdate: truein oh-my-opencode-slim; supermemory also announced an update (v2.0.10 → v2.0.11) during the session, suggesting update checks happen at startup
5. Data / cache directories
~/.local/share/opencode: 151.8 MB (includeslog/,repos/,snapshot/,storage/,tool-output/,auth.json,opencode.db+opencode.db-shm+opencode.db-wal)~/.cache/opencode: ~1.7 GB (1,701.9 MB)- Note: the workspace project itself is small (node_modules 19 MB, dist 4.8 MB, total 27.9 MB), so project size is likely not the bottleneck.
Suspected causes (in likely order of impact)
- Skill catalog scan — 144 skills across three directories are enumerated/parsed on every launch; the global AGENTS.md forces skill-catalog awareness on every session start.
- MCP server startup —
"*"enables all MCP servers, each requiring process spawn + connection handshake (some are network-bound). - Plugin initialization — 4 plugins with an ~80 MB dependency tree;
oh-my-opencode-slimperforms update checks (autoUpdate: true) and preset resolution. - LSP boot —
"lsp": trueinitializes language servers on startup for the workspace. - Large cache/database — 1.7 GB cache and a 150 MB+ share directory (SQLite WAL files present) may add I/O cost during startup/db initialization.
- Desktop shell overhead — the desktop wrapper itself plus model endpoint connectivity check before the UI becomes interactive.
Requested help
- Confirm which of the above dominates startup time (I can provide
--log/ verbose startup output if there is a recommended flag). - Advice on the cheapest wins, e.g.:
- Pruning the skill directories or deferring skill scanning until first use
- Tightening
mcpsfrom"*"to only the servers actually needed - Disabling
autoUpdate/ update checks at startup - Cleaning
~/.cache/opencodeand compactingopencode.dbWAL - Any documented startup profiling flag for the desktop app
Reacted by RedoSan, Laventiy Flow and Samuele Facenda
Activity
github-actions commentedon Aug 10, 2026
This issue might be a duplicate of existing issues. Please check:
These issues cover similar startup latency symptoms. It may be worth adding your findings there, as your detailed environment breakdown (144 skills, MCP server startup, plugin initialization) could help existing investigations.
Redo-San commentedon Sep 30, 2026
Measured on Windows 10 Pro 19045, i7-4810MQ (4C/8T), 31.9 GB RAM. CLI
opencode-ai 1.18.12, Desktop1.18.33.The surprising part: CLI and Desktop burn nearly the same CPU to start, which points at the shared core rather than Electron.
app starting->server readySo Desktop is roughly 2x on memory and 1x on CPU: 7 Electron/Chromium processes plus the core.
Individual levers did not move the CPU number. Disabling LSP, plugins and MCPs changed nothing;
--puregave 9.9 CPU-s and an empty config dir 9.5 CPU-s. So it is not one config entry doing the work.Caveats so the numbers are not over-read: these are single runs, and repeated CLI samples spread about 20-25%, so treat them as magnitudes rather than exact figures. I also did not use
opencode debug startupas the total, since it reported roughly 8x less than wall/CPU.Happy to share raw sampler output or re-measure with 3-run medians if that is useful.
Redo-San commentedon Sep 30, 2026
Correction: my earlier comment said CLI and Desktop burn "nearly the same CPU to start" and offered 3-run medians. I have now taken them, and they do not support that claim.
Desktop first-12s CPU is a median of 17.5 CPU-s against the 11.2-12.2 CPU-s CLI range I quoted — about 1.5x, not 1x. The windows also differ: the CLI wall window was never recorded, and the Desktop 12s window includes post-ready work (directory bootstraps, watchers, skills) that the CLI figure may not. So the correct statement is that the CPU comparison is unresolved, not that the two are equal. The memory half of the claim is unaffected.
Desktop cold starts, median of 3 (raw runs in
runs/):spawning sidecar->server ready(s)app starting->server ready(s)Caveats on my own numbers, so they are not over-read:
peak busyhit 4.5-4.8 cores, but only as a ~250ms burst. The busiest sustained second is ~1.8 cores and the 45s average is ~1.2. The average is the honest number, not the peak.Two things the repeated runs surfaced, both straight from the core log and consistent across all three:
all LSPs are disabled/all formatters are disabled:C:\Users\pc,F:\RedoSan Authenticity,G:\FL Proj. Fewer workspace roots should be a direct lever.spawning sidecar, and afterupdater state changed { to: 'up-to-date' }. That is ~2.0-2.8s of a 3.5s startup window, running concurrent with the sidecar boot rather than strictly on top of it.The wall clock is very stable (
spawning sidecar->server readyspans 2.98-3.00s, under 1%) while CPU in the same window swings 11.2-17.5 CPU-s. That reads as concurrent CPU work finishing while other work waits, rather than latency that grows with load.Same environment: Windows 10 Pro 19045, i7-4810MQ (4C/8T), 31.9 GB RAM. Desktop 1.18.33, CLI 1.18.12.
opencodejr commentedon Oct 28, 2026
Thanks for the report! Before we can look into this, we need a few things:
opencode --version). OpenCode v1 (0.x/1.x) and v2 (2.x) are completely separate implementations, so this decides where the report goes. Your config ("lsp": true,"snapshot": false, plugins such asoh-my-opencode-slim) looks like v1. v1 only gets critical fixes now.~/.local/share/opencode/log/right after a slow start. It also helps to know whether the delay is still there with plugins and MCP servers temporarily disabled.You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.
These existing issues might be related, most likely first:
almirus commentedon Oct 29, 2026
opencode-debug-20261029T074030.zip
opencodejr commentedon Oct 31, 2026
We're closing this issue for now because we haven't heard back. To look into the slow desktop startup, we need to know which OpenCode version you're on (v1 and v2 are separate implementations). We'd also need how you installed the app, a short description in your own words of what you see while it loads, and the log from one slow launch.
If it still happens, please reply here with those details or open a new issue and we'll take another look. You may also want to follow #52271 and #59597, which are about related desktop startup delays. Thanks!