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

[wilanahattingh]

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.

[danyel117]

Thanks for the detailed report. I reproduced the empty catalog on a clean first start with OpenCode 1.18.25 and plugin 0.1.49, but the differential points to the host's first npm-load lifecycle rather than the plugin's V1 registration API:

• fresh isolated cache, first process: 0 goal commands / 0 goal tools;
• restart with the exact same config and cache: /goal, /pause_goal, /resume_goal plus all 9 goal tools appear;
• loading the exact published dist/server.js via file:// with the workspace x-opencode-directory header: all commands/tools appear immediately.

The v1.18.25 source also does invoke V1 config hooks and consume hook.tool; the successful cached/file loads confirm those paths work once the plugin module is loaded.

Could you fully exit OpenCode after the first install, start it again with the same cache/config, and then query the workspace instance (including its x-opencode-directory header) to confirm whether the 3 commands and 9 tools appear? If the restart fixes it, I'll treat this as an upstream first-install loader bug and open/link the minimal upstream repro rather than changing this plugin's compatibility range or registration logic.

[pablobion]

I was having the same problem; I cleared the 'goal' folder in .cache/packages and it started working again.

[danyel117]

Thanks — that cache result helps narrow this down. Could you confirm the exact OpenCode and plugin versions, the exact cache directory you removed, and whether a full OpenCode restart with the unchanged cache still left the commands/tools absent before you deleted it? That will distinguish a stale/corrupt package extraction from the first-install loader lifecycle and determine whether the fix belongs in this plugin or upstream.