[Bug][Grok Build CLI] Hooks from plugins and Claude-compat import show as loaded/trusted but are never dispatched

[akunzai]

Environment

• grok 1.0.3 (1a29d5bc12d4) [stable]
• macOS (Darwin 25.6.0)

Summary

Hooks sourced from an installed plugin, or imported via Grok's
Claude-compatibility scanner (the "Claude settings" group in the Hooks tab),
are shown in the UI as loaded and trusted, but are never actually dispatched
when their event fires. Only hooks placed directly under the global
~/.grok/hooks/*.json directory are dispatched.

Repro steps

1. Create a plugin with a hooks/hooks.json containing a Stop hook (a
   simple command that writes to a file, or exits non-zero with a message).
2. grok plugin install <path> --trust
3. Confirm in the Hooks tab (/hooks) that the hook appears under a
   dedicated Plugin: <name>-<hash> group, not blocked.
4. Launch grok with --debug-file <path> (works with both a brand-new
   session and --resume of an existing one — both reproduce identically).
5. Send any prompt and let the turn complete (triggers Stop).
6. Grep the debug log for hook_event= and loaded hooks hook_count=.

Expected

The Stop hook fires: a hooks.dispatch{hook_event=stop ...} span appears in
the debug log, and the hook's side effect (file write / exit-2 message)
happens.

Actual

• xai_grok_shell::session::acp_session::spawn: loaded hooks hook_count=1
  at session spawn — this is only the global hook(s) under ~/.grok/hooks/;
  the plugin's hook is not among them.
• xai_grok_hooks::discovery: hooks: discovery complete total_hooks=0 ... stop=0 ... — even though the plugin manager
  (xai_grok_agent::plugins::discovery) separately logs has_hooks=true
  for the plugin.
• After the turn completes, no hook_event=stop (or hook_event=post_tool)
  dispatch span appears anywhere in the log. The hook's side effect never
  happens.

What I ruled out

• hooks.json format: byte-for-byte the same schema as a working global
  hook file (~/.grok/hooks/herdr.json, SessionStart, loads and dispatches
  fine), and the same schema xAI's own grok-build-plugin-cc Claude Code
  plugin uses for its SessionStart/SessionEnd hooks.
• Trust: installed with --trust; the Plugins tab shows it under
  "Direct installs", not blocked.
• Claude Code plugin-name collision: reproduced after fully uninstalling
  the same-named plugin from Claude Code (claude plugin remove), so it
  isn't the Claude-compat import path shadowing a native install.
• --resume vs. fresh session: identical hook_count=1 /
  zero-stop-dispatch result on both a --resumed session and a brand-new
  one (start_type="new").

Notes

Filed after searching xai-org/plugin-marketplace (open + closed, several
phrasings) and xai-org/grok-build-plugin-cc for a duplicate — didn't find
one. xai-org/grok-build itself has no issue tracker.

Happy to share the full --debug-file output or the minimal repro plugin
directory if useful.

[akunzai]

Follow-up: not event-specific — tested across 6 event types, none dispatch from a plugin

Built a minimal throwaway plugin (hooks/hooks.json only) whose hooks each
append their own event name to a log file, covering every event type
reachable without extra setup (no approval-prompt or subagent scaffolding
needed): SessionStart, UserPromptSubmit, PreToolUse, PostToolUse,
Stop, SessionEnd.

grok plugin install <path-to-probe-plugin> --trust
grok --debug-file <path>   # fresh session

Drove a full lifecycle in that session: launch (SessionStart) → prompt
submit (UserPromptSubmit) → a real tool call, echo probe-test-tool-call
(PreToolUse/PostToolUse) → turn completion (Stop) → /exit (SessionEnd).

Result: the probe's log file was never created — none of the six event
types fired. The debug log's only hooks.dispatch{...} span for the entire
session remained the single global ~/.grok/hooks/*.json hook
(hook_event=session_start), same as in the original report.

For contrast: a global ~/.grok/hooks/*.json file with a Stop hook (not a
plugin) does dispatch correctly and is confirmed working in production use.

So this isn't limited to Stop/PostToolUse, and it isn't an artifact of
those two events specifically — it looks like the plugin-hook source is
entirely disconnected from the session's hook dispatcher for every event
type, while the global-hooks-directory source works normally. Happy to share
the throwaway probe plugin if it's useful for a fix.