You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A TUI plugin installed via opencode plugin <npm-package> --global silently fails to load when its .tsx source uses JSX syntax. The @opentui/solid/jsx-dev-runtime specifier that is injected by bun's native JSX transform is resolved natively relative to the plugin file (bypassing the runtime-plugin rewrite loader), and npm-installed plugins live under ~/.cache/opencode/packages/<pkg>@<ver>/node_modules/<pkg>/, which has no upward @opentui to resolve against. Result: Cannot find package '@opentui/solid', consumed as a silent no-op (no sidebar, no plugin entry) — that's #41574's diagnostic gap in action.
Root cause (debugged)
Running the plugin outside the dev overlay (~/.cache/opencode/packages/...):
Loading the npm ./tui entry with JSX present → IMPORT FAILED: Cannot find package '@opentui/solid'.
The REWRITE-LOADER in the runtime-plugin support fires for the file itself, but not for the dev-runtime import bun injects, because that injection happens in the native transform after rewriting (or is resolved by a code path that ignores plugin resolvers).
Removing every JSX expression and importing jsxDEV explicitly from "@opentui/solid/jsx-dev-runtime" makes the same file import cleanly from the identical cache location: the explicit import is a runtime specifier → rewritten to the correct virtual module. Confirmed in 1.18.31's install-store layout.
So the bug is specifically: JSX syntax in plugin sources is unsupported for npm-installed plugins, while repo/dev-overlay plugins work because their location happens to resolve upward into the app's node_modules.
The same failure likely underlies parts of #33884 (npm-spec plugins silently failing) and the "render once / never updates" #48883 path.
Repro
opencode plugin opencode-token-min --global (uses exports["./tui"], verified on 1.18.31).
The installed copy at ~/.cache/opencode/packages/opencode-token-min@<ver>/node_modules/opencode-token-min/tui/token-min.tsx contains <box>/<text> JSX.
Start a TUI session → no sidebar from the plugin; nothing in logs.
Import the file through the runtime-plugin support from that path → Cannot find package '@opentui/solid'.
Suggested fixes (any one)
Run the plugin-rewrite loader after the native TSX transform so injected dev-runtime specifiers are also rewritten.
Make the rewrite loader catch specifier rewrites for injected imports (resolve @opentui/... against the host runtime).
Keep plugin sources JSX-free: import { jsxDEV } from "@opentui/solid/jsx-dev-runtime" and build elements with jsxDEV("box", { children: [...] }). Added to opencode-token-min v1.0.2.
Context: related #27447, #48883, #33884, #41574, #39986.
Debugging performed by the opencode agent (Big Pickle), supervised by tmiland.
The reproduction is clear: JSX in an npm-installed TUI plugin causes Bun’s injected @opentui/solid/jsx-dev-runtime import to bypass the runtime-plugin rewrite path, so the plugin cannot load from the cache location.
I’ll trace the plugin rewrite and loader flow, add a focused regression case for an installed .tsx plugin, and make sure load failures remain visible without changing the development overlay path.
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.
Activity
LeoParkerOu commentedon Sep 22, 2026
I’d like to work on this issue.
The reproduction is clear: JSX in an npm-installed TUI plugin causes Bun’s injected @opentui/solid/jsx-dev-runtime import to bypass the runtime-plugin rewrite path, so the plugin cannot load from the cache location.
I’ll trace the plugin rewrite and loader flow, add a focused regression case for an installed .tsx plugin, and make sure load failures remain visible without changing the development overlay path.
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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊