Nothing registers on opencode 1.18.25: /goal commands and goal tools silently absent #54

Summary

On opencode 1.18.25 (both the desktop app and the opencode-ai@1.18.25 npm CLI), the plugin installs and imports cleanly but nothing registers: no /goal, /pause_goal, /resume_goal commands and none of the *_goal tools. There are no errors in the opencode log — the failure is completely silent.

Environment

• opencode: 1.18.25 (verified on both the desktop app and the npm CLI)
• plugin: @prevalentware/opencode-goal-plugin@0.1.49 (latest)
• OS: Windows
• Config (global ~/.config/opencode/opencode.json): "plugin": ["@prevalentware/opencode-goal-plugin"], plus the same entry in tui.json

Evidence

1. Install path (npm): the package is downloaded and installed into ~/.cache/opencode/packages/@prevalentware/opencode-goal-plugin@latest with a full node_modules tree at server start. The merged /config response contains "plugin": "@prevalentware/opencode-goal-plugin". No plugin errors appear in opencode.log (only unrelated skill warnings).
2. Live server query (desktop): GET /command returns 125 commands, none of them goal. GET /experimental/tool/ids returns 14 tools, none of them *_goal.
3. Clean-room repro (CLI 1.18.25, isolated XDG_CONFIG_HOME/XDG_DATA_HOME/XDG_CACHE_HOME): configured the plugin as a local file:// URL pointing at the cached dist/server.js (bypassing npm install and the engines/compatibility gate entirely). Server boots healthy, instance bootstrap completes, no failed to load plugin / plugin config hook failed log entries. Still:
   • GET /command → 130 commands, no goal
   • GET /experimental/tool/ids → 14 tools, no *_goal
   • Forced plugin initialization by creating a session (POST /session), then re-queried /command → still no goal

Root-cause analysis (against v1.18.25 source)

• packages/opencode/src/command/index.ts builds the command catalog once inside Command.state (an InstanceState-cached init) by iterating cfg.command from config.get(). The plugin's V1 registration works by mutating config.command inside its config(cfg) hook (registerDesktopCommands), but the mutation never becomes visible to the command list — either because the hook's cfg is not the object the Command service reads, or because Command.state initializes/caches before the hook runs. In my clean-room test, forcing plugin init before querying /command did not help.
• packages/opencode/src/plugin/index.ts at v1.18.25 contains no consumer of the V1 tool: { ... } hooks object, and no *_goal tools appear via /experimental/tool/ids.
• Side note: report.missing in the loader is a no-op, so an entry-detection failure would also be invisible — though in my file-based test the module demonstrably imported (default export { id, server, setup } with a server function matches readV1Plugin(..., "detect")).

Net effect: the V1 surfaces this plugin relies on (config-hook command injection + hook.tool) do not take effect on the 1.18.x Effect-based rewrite, so the package's engines: ">=1.17.1" bound appears too permissive. The context.command.transform path in setupV2 targets opencode 2 beta hosts.

Expected behavior

/goal etc. appear in the command catalog on opencode 1.18.25 (or the plugin degrades loudly — e.g. logs once that the host does not support command registration) rather than loading inertly.

Suggestions

• Either fix V1 registration for the 1.18.x line, or narrow engines / emit a startup warning when the host build ignores config-hook command injection, so users get a visible signal instead of a silently inert plugin.
• Happy to test any candidate fix on the same clean-room setup.