Repository navigation
First launch can stall on project .opencode dependency install #47212
Description
Description
On the first OpenCode launch in a fresh git worktree containing .opencode/skills, the TUI stayed completely blank and could not accept input. The OpenCode process remained alive.
The last logs for that run were the config paths loaded during bootstrapping; the usual LSP and formatter initialization logs never appeared. During the stall, OpenCode generated .opencode/package.json and node_modules, then wrote .opencode/package-lock.json 61 seconds after bootstrap began.
opencode --pure --print-logs --log-level DEBUG debug config later completed the same bootstrap in 216 ms. After the generated dependency files existed, a normal non-pure run completed in 254 ms.
This appears to be the per-directory Npm.install() for @opencode-ai/plugin blocking Plugin.init() through Config.waitForDependencies() whenever local plugins exist. The first launch provides no progress or timeout while waiting.
Expected behavior: the TUI should render promptly, or show dependency-install progress and fail within a bounded time.
Related issues:
- Instance bootstrap can hang indefinitely — plugin.init() npm install has no timeout and the per-directory boot promise is cached #33905 describes the same unbounded
Config.waitForDependencies()mechanism, but was closed as a duplicate of an unrelated no-plugin rendering issue. - Plugin import hangs silently when resolving npm specifiers (e.g. oh-my-openagent@latest) #31463 covers cold-cache Arborist hangs while installing npm-specifier plugins into the global cache. This report concerns the generated project
.opencodeinstall. - .opencode/node_modules/ causes startup hang — scanner doesn't skip node_modules despite .gitignore #30337 covers generated
.opencode/node_modules, but attributes the delay to scanning an existing dependency tree. - 1.18.21: plugin installer times out fetching public deps from registry.npmjs.org (NpmInstallFailedError: FetchError) — silent dead plugin / boot hang; headless run/serve hangs with any plugin #44684 reports related plugin installation and boot hangs in 1.18.21.
Plugins
Four local file plugins under ~/.config/opencode/plugins: herdr-agent-state.js, herdr-worktree-identity.ts, test-oracle-guard.ts, and zsh-reserved-name-guard.ts.
OpenCode version
1.18.20
Steps to reproduce
- Configure at least one local file plugin under
~/.config/opencode/plugins. - Open a fresh checkout or git worktree containing
.opencode/skills, with no generated.opencode/package.json,package-lock.json, ornode_modulesyet. - Run
opencodein that worktree. - Observe the blank TUI while the per-directory dependencies are installed.
- Start OpenCode again after the dependency files exist; startup is fast.
Screenshot and/or share link
The affected pane was entirely blank, and no share session was created.
Operating System
macOS 14.7.4
Terminal
Herdr 0.8.2
Activity
github-actions commentedon Sep 4, 2026
This issue might be a duplicate of existing open issues. Please check:
These cover the same unbounded
Npm.install()/ bootstrap hang you've described. If your report adds new context (the per-directory.opencodeinstall path specifically, as distinct from the global cache path in #31463), it may still be worth keeping open — but please check those issues first and comment there if they already capture the problem.benjaminshafii commentedon Oct 3, 2026
Another data point for the same mechanism, this time for the global config dir and file-path plugins, on Windows (OpenCode 1.18.30,
opencode serve).When an embedder configures plugins as absolute file paths (self-contained bundles that don't import
@opencode-ai/plugin), the first instance bootstrap on a fresh profile still waits forNpm.install(Global.Path.config, { add: ["@opencode-ai/plugin@<version>"] })throughConfig.waitForDependencies()before it loads any plugin.First request for a folder on a fresh profile:
windows-2022runnermacos-15With the same tree pre-installed in
~/.config/opencode, the first request takes 0.4 s on Windows. The install is 3,669 files, mostlyeffect. On Windows, a warm npm cache and a Defender exclusion each save only 1–5 s, so arborist's file writes account for most of the time.Suggestion: skip
waitForDependencies()(or don't block on it) when every configured plugin is a local file path, or at least bound it and log progress. As a workaround we now ship the pre-resolved tree and unpack it on fresh profiles.connect-opencode: write the catalog, because opencode never reads /v1…
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊