plugin hot-reload failure wipes config-defined providers until service restart #53526

Summary

When a local plugin file under ~/.config/opencode/plugins/ is edited while the background service is running, the plugin hot-reload fails with a TypeError and all config-defined providers are wiped from the provider registry until the service is restarted. In our setup this silently breaks an auth-bridge provider (requests bypass its configured baseURL and hit the upstream API directly with an invalid credential).

Environment

• opencode version: 2.0.24 (channel: latest, npm @opencode/cli)
• OS: Debian 12, Linux 6.1.0-53-amd64 x86_64
• Terminal: rxvt-unicode-256color (urxvtd daemon)
• Shell: /bin/bash
• Install/channel: latest release
• Active plugins:
  • npm: [email protected], [email protected]
  • local: ~/.config/opencode/plugins/rtk.ts, ~/.config/opencode/plugins/llm-rate/ (directory plugin: index.ts server half + tui.tsx TUI half importing @opencode/plugin/tui)

Reproduction

Observed 4 times consistently (4/4) today; exact steps from our setup:

1. Run OpenCode (persistent background service, opencode serve --service) with a config that defines providers in the providers block, e.g. one custom provider with package + settings.baseURL pointing at a local auth bridge, plus another custom provider.

2. With TUI sessions active, save any file in the local plugin directory (index.ts or the sibling tui.tsx) — even a valid, compiling change.

3. The log shows repeated errors:

   level=ERROR message="failed to reload plugins" cause="Cause([Die(TypeError: oe is not a function. (In 'oe()', 'oe' is an instance of Object))])"
   

4. Query the provider registry from a new CLI context:

   opencode api provider.list

   Config-defined providers are gone — only built-in discovery entries remain (anthropic, openrouter, opencode), and the anthropic entry has no settings (no baseURL, no apiKey).

5. Requests through the affected provider now bypass its configured baseURL (our auth bridge on 127.0.0.1:8787) and go directly to the upstream API, failing with API key is invalid.

6. Killing the opencode serve --service process and relaunching restores all providers (config is correct; nothing else changed).

Expected Behavior

• The plugin hot-reload either succeeds or fails without mutating the provider registry.
• Config-defined providers (and their settings) survive a failed plugin reload.

Actual Behavior

• Plugin reload throws TypeError: oe is not a function. (In 'oe()', 'oe' is an instance of Object) (minified).
• The provider registry loses every config-defined provider until the service is restarted; only restart restores them.

Additional Context

• Frequency: consistent — 4 distinct incidents on the same day (~10:01, 10:38, 10:53, 11:03 UTC), 29 failed to reload plugins error lines in the log.
• Trigger was saving an edit to the plugin directory; the edited file always compiled cleanly (validated with esbuild beforehand in later incidents).
• Tried: making the TUI-half file export an inert plugin object when the TUI runtime is absent (guessing the server-side reload also imports it and throws on Plugin.define) — did not help; the wipe still occurred. We could not isolate whether the TypeError comes from our plugin code or the reload path itself (minified bundle).
• Impact detail: the wipe is sticky. The plugin code itself may successfully hot-reload on a later save while providers stay missing, which makes the failure confusing (widget updated, sessions broken).
• Diagnostic note: provider.list output from a transient CLI-spawned context can differ from the running service; the wipe was confirmed on the running service by observing requests bypass the configured baseURL (connection-level check via ss -tnp).
• Workaround: batch plugin edits and restart the background service after every edit.