Grok Build: nowledge-mem hooks never register (trust/update gap) — auto capture silent-fails

[cicae]

Summary

On Grok Build, automatic session capture (Stop / PreCompact / SessionEnd → nmem t save --from grok) does not run because the plugin’s lifecycle hooks never register in the session, even when the plugin is installed, enabled, and skills/commands load normally.

This is distinct from #472 (hooks fire but host defaults to claude-code). Here hooks appear absent from Grok’s hook_execution log entirely—so capture cannot succeed or fail; it simply never starts.

Manual nmem t save --from grok works. nmem status is healthy. The failure mode is silent and easy to misread as “Mem is broken” or “not configured.”

Environment (minimal)

Component	Value
Grok Build CLI	1.0.0 (recent sessions also logged as 0.2.12x)
nowledge-mem plugin	0.7.22 (nowledge-co/community#nowledge-mem-claude-code-plugin)
nmem CLI / server	0.10.55, local, status ok
OS	macOS 26.6

Config: [plugins] enabled = ["nowledge-mem"].

Expected

After install (ideally with Grok’s --trust):

1. SessionStart / Stop / PreCompact / SessionEnd hooks from the plugin appear in Grok’s hook runner.
2. Each completed turn auto-captures to Mem as source: grok (thread_id like grok-<session_id>).
3. Plugin update does not silently drop capture; trust either persists or is re-prompted.

Docs currently read as if install alone is enough for automatic capture under Grok.

Actual

1. Plugin enabled → skills and slash commands load.
2. In session updates.jsonl / hook_execution events, only global hooks run (user hooks under ~/.grok/hooks/). No plugin-scoped nowledge-mem hooks appear.
3. Local Grok transcripts accumulate under ~/.grok/sessions/, but Mem gains no new source=grok threads until a manual save/backfill.
4. Pattern recurred around Grok CLI + plugin update windows (fix attempts → worked-looking state via backfill → silence again after updates).
5. grok plugin install … --trust does not leave an observable durable trust state on disk; Grok’s binary surfaces trust-store failure strings (failed to read trust store; no plugins will be trusted). Skills still load (enable path), hooks stay inactive (trust path).

So: enable ≠ hooks running under current Grok Build plugin trust behavior.

Reproduction

1. Install nowledge-co/community#nowledge-mem-claude-code-plugin (with or without --trust); ensure enabled.
2. Confirm nmem status ok and skills like save/search are visible in Grok.
3. Start a new Grok session in a project that already has local history under ~/.grok/sessions/.
4. Complete a turn; inspect session hook_execution names.
5. Observe: no nowledge-mem plugin hooks; Mem has no new grok-* thread.
6. Run nmem t save --from grok -p . → succeeds immediately.
7. After grok plugin update / CLI upgrade, recheck—hooks still missing or regress without a clear trust prompt.

Impact

• Users believe Grok Build ↔ Nowledge Mem “auto-syncs”; gaps look like product outages.
• Same class of failure as Grok Build: Stop/PreCompact capture always uses --from claude-code and fails silently #472 (zero auto source=grok threads), different layer (hooks not scheduled vs wrong --from).
• Silent: no error toast when hooks never load.

Workarounds (verified locally)

1. Global always-trusted hooks under ~/.grok/hooks/*.json that call the plugin’s nmem-hook-save.py (or nmem t save --from grok) on Stop / PreCompact / SessionEnd.
2. Symlink/copy plugin into ~/.grok/plugins/ (Grok docs: auto-trusted path).
3. Manual / scheduled backfill: nmem t save --from grok -m all -p <project>.

Requests

Host (Grok Build) — primary fix surface

Please treat as a Grok plugin-runtime bug (also sending via Grok /feedback):

• install --trust should persist trust so plugin hooks register on subsequent sessions.
• plugin update should preserve trust or re-prompt; do not leave “enabled skills, dead hooks.”
• Surface trust/hooks status in /plugins / /hooks when a plugin’s hooks are blocked.

Nowledge plugin / docs — secondary

1. Grok install docs: state explicitly that Grok requires plugin trust for hooks, that enable alone is insufficient, and how to verify (hook_execution / /hooks shows plugin hooks; a test turn creates grok-* in Mem).
2. Document update regression: after Grok or plugin update, re-verify capture.
3. Optional: ship or document a global-hook fallback install snippet for Grok when host trust is flaky (mirrors what works today under ~/.grok/hooks/).
4. Cross-link Grok Build: Stop/PreCompact capture always uses --from claude-code and fails silently #472: even when hooks fire, host detection must use --from grok (already improved in later changelog; still worth a Grok verification matrix).

Related

• Grok Build: Stop/PreCompact capture always uses --from claude-code and fails silently #472 — hooks fire but --from claude-code (different failure mode)
• Grok docs: enable loads skills; trust gates hooks/MCP/LSP; ~/.grok/plugins/ auto-trusted

Happy to provide redacted hook_execution name lists if useful (no full transcripts).

[wey-gu]

Thanks. The important signal here is that commands/skills load but lifecycle hooks never enter Grok hook_execution. That points at host trust/update/registration rather than the actual nmem sync command.

I am going to keep this separate from #472: #472 is a wrong --from claude-code hook payload path; this issue is earlier, where Grok Build does not register/run the hooks at all.

If you can share a redacted Grok Build plugin install path/config and any trust/update UI state, that will help us make the repair command or docs precise. No tokens or private project paths needed.

[cicae]

Happy to share a redacted layout from this machine.

Install / config

• CLI: Grok Build 1.0.0
• Plugin: nowledge-mem 0.7.22 via
  nowledge-co/community#nowledge-mem-claude-code-plugin
• Install root (pattern):
  ~/.grok/installed-plugins/community-nowledge-mem-claude-code-plugin-<hash>/
  with plugin at …/nowledge-mem-claude-code-plugin/
• ~/.grok/installed-plugins/registry.json: records git URL + commit + subdir + version;
  no trust field
• ~/.grok/config.toml:
  [plugins] enabled = ["nowledge-mem"] only — no trust-related keys
• grok plugin list: shows the community install entry as expected

Trust / update UI state (what we can observe)

• No durable plugin trust file found under ~/.grok/ after install (including with --trust attempts earlier).
• Folder trust file ~/.grok/trusted_folders.toml is absent.
• Host binary strings include failure paths such as
  failed to read trust store; no plugins will be trusted and a trusted-plugins store concept —
  we never see a corresponding on-disk trust grant that survives restarts/updates.
• Plugins modal: plugin enabled, skills/commands load; hooks path still looks inactive
  (MCP/hooks “blocked when untrusted” class of behavior). No clear re-prompt after
  grok plugin update / CLI upgrade when capture silently stops.

Runtime check

• Session hook_execution names are only global hooks
  (global/…), never plugin-scoped nowledge-mem hooks
  (Stop / PreCompact / SessionEnd / SessionStart from the plugin).
• Plugin hooks/hooks.json is present on disk under the install tree; it simply never appears in the runner.

Local workarounds currently in place

1. Symlink: ~/.grok/plugins/nowledge-mem → installed plugin tree
   (docs: auto-trusted path). Even with this, plugin-scoped hooks did not reliably show up
   when the enable path still binds the installed-plugins tree — possible canonicalize-to-untrusted.
2. Global always-trusted fallback: ~/.grok/hooks/nowledge-mem-capture.json
   calling scripts/nmem-hook-save.py (or nmem t save --from grok) on Stop / PreCompact / SessionEnd.

Happy to run any one-liner you want for further redacted diagnostics.