What this fixes

Fixes #33884.

Since v1.17.10, TUI plugins referenced by their npm package spec in tui.json (e.g. {"plugin": ["@slkiser/opencode-quota"]}) silently stop loading — no sidebar panel, no slash commands, no visible error. Server plugins and file:// TUI plugins are unaffected.

In plain terms

opencode installs an npm TUI plugin into its own isolated folder under ~/.cache/opencode/packages/<spec>/node_modules/<name>/. Because that folder has its own node_modules, the plugin loads its own copy of @opentui/solid instead of the one the opencode app is already running. OpenTUI's Solid renderer keeps a module-level RendererContext singleton, so "the app's renderer" and "the plugin's renderer" end up being two different objects. The plugin then tries to register its panel/commands against a renderer the app isn't using, so nothing shows up — and the failure happens deep in module resolution, so no error reaches the user.

A file:// plugin doesn't have this problem because it lives outside any node_modules directory, so OpenTUI's loader already rewrites its @opentui/* imports onto the app's instance. The npm-spec path is the only one that broke, and it broke when OpenTUI 0.4.2 (#33610) introduced dual bun/node entry files for @opentui/solid, which made the isolated copy diverge from the host copy.

Technical detail

OpenTUI's runtime plugin bridges bare @opentui/* imports onto the host's registered runtime modules, but for paths inside node_modules that bridging is gated behind rewrite options that default to nodeModulesBareSpecifiers: false. Non-node_modules (i.e. file://) plugins are bridged unconditionally.

The fix enables nodeModulesBareSpecifiers when opencode installs the OpenTUI Solid runtime support, so bare @opentui/* imports inside the plugin cache tree are rewritten onto the host's registered instances — giving npm-spec plugins the same renderer instance the host uses, exactly like file:// plugins already get.

ensureRuntimePluginSupport({
  additional: keymapRuntimeModules,
  rewrite: { nodeModulesBareSpecifiers: true },
})

One line of behavior change in packages/opencode/src/plugin/tui/runtime.ts, plus an explanatory comment.

Verification

Reproduced on macOS, opencode 1.17.10 (Homebrew), Bun 1.3.14, using @slkiser/opencode-quota:

• The host (Bun) resolves @opentui/solid to index.bun.js; the isolated plugin tree resolves a different @opentui/solid (index.js).
• Loading the runtime plugin with the current defaults and importing the plugin's dist/tui.tsx from node_modules yields host RendererContext === plugin RendererContext → false (separate instances), matching the reported silent failure.
• The file:// workaround works precisely because that path is bridged unconditionally.

See #33884 for the full investigation and evidence.

Notes for reviewers

• This relies on the rewrite plumbing already present in @opentui/core's runtime plugin (nodeModulesBareSpecifiers), so no upstream OpenTUI change is required.
• Worth a sanity check that enabling bare-specifier rewriting in node_modules doesn't pull additional packages through the rewrite loader in a way that affects startup; in testing it was scoped to the registered runtime specifiers (@opentui/*, solid-js, solid-js/store).