tool.execute.before/after hooks silently don't fire under "opencode run" (headless), unlike UI/session-driven runs

[sergiofspedro]

Summary

tool.execute.before/after plugin hooks appear to not fire reliably — or at all — for sessions started via opencode run (the one-shot headless CLI entry point), even though the same hooks fire correctly for equivalent sessions created through a UI-driven session (tested via OpenChamber, an OpenCode-based desktop/web wrapper).

Repro

• A custom plugin registers tool.execute.before/after and logs every invocation.
• A session started via opencode run "<prompt>" entered a loop calling two tools (get_goal and command_list, provided by a third-party plugin, @prevalentware/opencode-goal-plugin) 254 times in ~110 seconds.
• Zero log lines were emitted by our own hook-based plugin during that entire window — the hook was never invoked for either tool, across 254 calls.
• The same prompt/setup, run through a real UI session instead of the CLI, completed cleanly with no loop and normal hook firing (reproduced twice).

Related but distinct

#2319 ("MCP Tool Calls Don't Trigger Plugin Hooks"), closed and fixed by #2320, covered a related gap for MCP-routed tools in the interactive/UI path. This report is narrower: it's specific to the headless opencode run code path, affects a non-MCP plugin's own native-style tools, and reproduces cleanly against a UI session that does NOT show the same gap. It's unclear whether headless mode uses a different execution path than the session/UI runtime for hook dispatch, or whether this is a residual case #2320 didn't cover.

Question for maintainers

Does opencode run dispatch tool calls through a different internal path than session/UI-driven execution? If so, is hook dispatch wired up identically on both paths?

Environment

OpenCode 1.18.15, reproduced on both Linux (Docker) and Windows.