tui: local plugins silently fail to load on Windows since beta-18721 upgrade (cli.json migration regression) #46408

Activity

1. github-actions

   assigned

   simonklee

   on Aug 31, 2026
2. opencode-agent

   added

   2.0

   on Aug 31, 2026
3. github-actions commented on Aug 31, 2026

   

   github-actionsBot

   on Aug 31, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • tui: plugins no longer load after cli.json config migration (nightly next channel) #42051: tui: plugins no longer load after cli.json config migration — symptoms appear to match exactly (silent failure to load TUI plugins after cli.json migration, no diagnostics in logs). You already noted this in your report.

   If this is indeed the same root cause recurring on the beta channel / Windows, it may be best to continue tracking in #42051 rather than opening a new issue. If you've confirmed behavior specific to Windows or beta-18721 that differs from the existing report, please add a comment there with the additional details.
4. Just-Silver commented on Aug 31, 2026

   

   Just-Silver

   on Aug 31, 2026

   Author

   More actions

   Thanks for the triage. This is the same symptom family as #42051, but the report deliberately adds evidence the existing issue doesn't cover:

   • Platform: Windows (ties into the Windows-path import issue class [BUG] 「V2 (next-17444)」local .ts plugins fail to load on Windows #42763 / tui: local plugins fail to load on Windows #43644; tui: plugins no longer load after cli.json config migration (nightly next channel) #42051 is Linux-only)
   • Channel: beta channel, build beta-18721
   • Key evidence — version timeline: 0.0.0-beta-18707 loads plugins fine; 0.0.0-beta-18721 silently ignores every supported configuration shape (cli.json plugins, tui.json entries, official plugins/<name>/index.tsx layout). That gives a concrete regression range for bisecting the change that broke it.

   Happy to fold these details into #42051 if maintainers prefer single-issue tracking; keeping this open to represent the beta/Windows angle meanwhile.
5. MilkyWay008 commented on Aug 31, 2026

   

   MilkyWay008

   on Aug 31, 2026

   More actions

   The beta-18707 to beta-18721 regression range is a gift, that makes it bisectable. Since even a zero-dependency probe plugin doesn't load and plugin-meta.json never appears, the loader is dropping the config before it gets to imports, so it's probably the cli.json migration path rather than the Windows import issue (#42763). Worth checking whether beta-18721 rewrote your cli.json in place (compare against a backup or re-add the plugins entry), and confirming the duplicate #42051 tracks the same config-migration root cause, then fold your Windows evidence in there. Until it's fixed, staying on beta-18707 is the sane move.
6. Just-Silver commented on Sep 1, 2026

   

   Just-Silver

   on Sep 1, 2026

   Author

   More actions

   Update (2026-09-01): full root-cause breakdown after debugging on the current beta channel. Windows 11, 0.0.0-beta-18743 via npm i -g @opencode-ai/cli@beta. Same silent failure as beta-18721 — sidebar never renders. But with the service log (~/.local/share/opencode/log/opencode.log) and a probe plugin, the failure is now layered and fully evidenced:

   1. Discovery only accepts root-level direct .ts/.js files
   The original plugin layout ~/.config/opencode/plugins/tui/opencode-tui-usage.tsx (nested dir + .tsx + non-index name) is silently skipped. Package-directory layouts (plugins/<name>/index.tsx, plugins/<name>/tui.tsx) are also NOT discovered. Only a root-level direct probe.ts was picked up. Docs confirm the narrow shape ("direct .ts and .js files"). On beta-18707 the same .tsx layout loaded fine — so discovery regressed to strict filtering.

   2. Server-side plugin deps now resolve from disk node_modules
   After the entry is found, import "@opencode-ai/plugin" resolves against ~/.config/opencode/node_modules/ — which the official install never creates. First hit was a stale V1 @opencode-ai/[email protected] (installed months ago for V1 dev) failing with Cannot find package '@opentui/keymap'; after removing it, Cannot find package '@opencode-ai/plugin'. Manually installing the V2 deps (@opencode-ai/[email protected], @opencode-ai/theme, @opentui/core, @opentui/solid, solid-js) makes the server import succeed.

   3. The loader then fails on ?mtime= file URLs — this is the upstream bug
   Server log:

   WARN failed to load plugin target="C:\Users\13178\.config\opencode\plugins\opencode-tui-usage.ts?mtime=1788225222..."
   cause="ResolveMessage: Cannot find module 'C:/Users/13178/.config/opencode/plugins/opencode-tui-usage.ts?mtime=1788225222...'"
   

   The loader dynamically imports plugin entries as file://...?mtime=<ts> and the module resolver rejects query-string file URLs. This is the same class as #42481 (ERR_UNKNOWN_BUILTIN_MODULE: file:///...js?mtime=...) — and #42485 (SEA-safe import) is still unmerged.

   Pipeline note: dev was verified working on dab2637 (Aug 12, per #42051) yet both Aug-31 beta builds (18721, 18743) fail identically. There are no plugin-related commits on dev between the two builds (only a v1 backport), and the binary diff between beta-18707 and beta-18721 shows a full repack (module graph reorganized) with identical plugin-discovery string regions. The beta pipeline is not in sync with dev — the fix verified on dev has not reached the release channel.

   Requests: (1) merge #42485 (or equivalent fix) and ship it in beta; (2) confirm whether the release install is expected to provide the V2 plugin runtime deps on disk; (3) verify on Windows specifically — discovery narrowing + disk resolution + mtime URLs all interact there. Staying on beta-18707 until then.

   😕React with 😕1Reacted by dmartinez-kmm
7. Just-Silver commented on Sep 21, 2026

   

   Just-Silver

   on Sep 21, 2026

   Last edited by Just-Silver

   Author

   More actions

   Closing as resolved from my side.

   The silent-load failure is no longer reproducible. On 0.0.0-beta-19425 the plugin loads normally after adapting to the current plugin layout: a directory plugin directly under .opencode/plugins/ with a tui.tsx entry (the older nested plugins/tui/<name>.tsx shape is indeed no longer discovered, and a bare .tsx file is not either — only .ts/.js files and direct subdirectories are). The runtime module was also renamed @opencode-ai/plugin/tui → @opencode/plugin/tui with no compatibility remap.

   So the practical resolution: the discovery/layout narrowing plus the package rename accounted for what I hit; matching the new layout made everything work with no manual node_modules install and no ?mtime= failures.

   Thanks for the triage and the pointers to #42051 / #42485.
8. Just-Silver

   closed this as completedon Sep 21, 2026