Stop hook systemMessage JSON not rendered as visible Line in v2.1.114 (plugin-scope dispatch)

[jphein]

Summary

In Claude Code 2.1.114, Stop hooks dispatched from a plugin (hooks.json) no longer render their {"systemMessage": "..."} JSON output as a visible <Line> in the terminal, even though the hook script exits 0 and outputs clean JSON to stdout.

Settings.local.json-registered Stop hooks appear to have broken more thoroughly in 2.1.114 (no invocation at all in some sessions), which led me to migrate the hook to a plugin. The plugin-scope dispatch does invoke the hook, it does read its stdout, and the subsequent stop_hook_active:true handling works — but the systemMessage no longer surfaces to the user.

Environment

• Claude Code: 2.1.114 (Claude Code) (binary symlinked from ~/.local/bin/claude)
• OS: Ubuntu (Linux 6.17)
• Plugin: MemPalace fork — registered Stop + PreCompact via plugin hooks.json
• Hook script: bash ${CLAUDE_PLUGIN_ROOT}/hooks/mempal-stop-hook.sh → invokes python -m mempalace hook run --hook stop --harness claude-code

What I observe

The hook runs. The hook saves data. The hook prints JSON to fd 1 (stdout), separate from any log noise on fd 2 (stderr). Verified by running the exact script Claude Code dispatches:

$ echo '{"session_id":"...","transcript_path":"...","hook_event_name":"Stop","stop_hook_active":true,"cwd":"..."}' \
  | bash ~/.claude/plugins/cache/mempalace/mempalace/3.3.1/hooks/mempal-stop-hook.sh > out 2> err
$ cat out
{
  "continue": true,
  "suppressOutput": false,
  "systemMessage": "✦ 30 memories woven into the palace — stop, hook, readme"
}
$ cat err
Diary entry: diary_memorypalace_20260418_... → memorypalace/diary/checkpoint

But in the terminal UI, nothing shows — not the Stop says: line, not the ✦, not even a collapsed ● Ran N stop hooks summary. Silent success on the UI side even though the producer side is clean.

Expected behavior

Per prior documentation and my own prior working session (2026-04-10 through 2026-04-17, pre-upgrade), a Stop hook outputting {"systemMessage": "✦ ..."} renders as a visible single-line <Line> element via AttachmentMessage.tsx handling hook_system_message attachments. Described as: "silent success is invisible by design — but the systemMessage Line is the one visible signal."

What I tried

1. Confirmed the hook fires (diagnostic probe file at /tmp/stop-hook-probe shows Claude Code invoking the script).
2. Confirmed stdout contains clean JSON (not mixed with stderr log lines).
3. Added continue: true, suppressOutput: false alongside systemMessage — no change in rendering.
4. Marker advances and diary drawers are written — the save path is healthy.

So the regression appears to be on the UI side: either AttachmentMessage.tsx no longer emits the hook_system_message <Line> for plugin-dispatched Stop hooks, or the attachment is being suppressed somewhere between hook-output capture and render.

Repro (minimal)

Any plugin with a Stop hook that outputs {"systemMessage": "test"} to stdout. Expected: a visible Stop says: test line. Actual: nothing visible, even though save-side side effects succeed.

Impact

Any plugin using silent-save patterns (non-blocking, direct data writes with user-visible confirmation via systemMessage) loses its only visibility signal. The pattern is deliberately non-blocking by design; systemMessage was the UX bridge. Without rendering, users can't tell anything happened.

Additional context

• Verified save still works end-to-end (data lands in vector store).
• MemPalace plugin upstream PRs with related workarounds: https://github.com/milla-jovovich/mempalace/pulls?q=is:pr+author:jphein
• Companion fix for a related suppression bug (where stop_hook_active:true was silently eating auto-saves in block-mode-guarded silent hooks): filing on the MemPalace side as upstream-fix/silent-save-visibility.

Happy to provide additional traces if helpful.

[jphein]

Clarifying observation from the user side: the hook-running indicator does flash briefly in the terminal (for ~1 second) and then disappears, rather than remaining as an expandable ● Ran N stop hooks (ctrl+o to expand) summary.

So the regression is more specifically: the hook-output attachment/Line is being rendered transiently and then removed, instead of persisting. That's why there's no way to press ctrl+o even when I try — the line is gone by the time my fingers move. Silent success should stay visible as the systemMessage <Line> — in 2.1.114 it appears and is then discarded within ~1 second.

Pre-2.1.114 behaviour (this same plugin, same format, same script): the Stop says: ✦ … Line rendered as a persistent single-line attachment. No action required to see it, no expansion needed.

[github-actions]

Found 3 possible duplicate issues:

1. SessionStart hook systemMessage no longer rendered in terminal #41285
2. SessionStart hook systemMessage not displayed when remote control is enabled via /config #47828
3. [BUG] PreToolUse/PostToolUse warn hook systemMessage silently dropped without hookSpecificOutput #40380

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[jphein]

Follow-up observation: after emitting the full Stop hook schema (continue:true, suppressOutput:false, alongside systemMessage), the Stop says: ✦ … Line rendered persistently once out of three consecutive fires in the same session. The two that didn't render: same hook, same JSON shape, identical output on fd 1 — verified externally by capturing stdout of the hook script. No apparent difference in input payload or environment between the renders-and-persists case and the silent cases.

So the regression isn't strictly about output shape — it's intermittent. Full-schema output may improve the odds but doesn't guarantee rendering. Leaves the underlying cause (in AttachmentMessage.tsx or wherever hook attachments attach to the transcript) as the real fix target.

[jphein]

Possibly related cluster of plugin-hook regressions:

• Bug: prompt-type Stop hooks always fail JSON validation, forcing dangerous workarounds that cause runaway background processes and unexpected billing #41393 — prompt-type Stop hooks fail JSON validation
• Plugin hooks fire twice: marketplace source + cache both loaded #24115 — plugin hooks fire twice (marketplace source + cache both loaded)
• Plugin hooks not loaded from external hooks.json file #16288 — plugin hooks not loaded from external hooks.json file

Happy to test together if the attachment-rendering fix also touches the dispatch path.

Updated rendering count: 2 of 4 recent fires now render the Stop says: ✦ … Line persistently after adopting the full Stop hook schema (continue:true, suppressOutput:false, systemMessage:…). Up from 1 of 3 in the earlier comment. Same hook, same JSON shape every fire — still intermittent, but the full schema does appear to improve odds. No obvious pattern to which fires render vs stay silent.

[jphein]

Follow-up — after several more fires, the Stop says: ✦ … Line now appears to render consistently with the full Stop hook schema (continue:true, suppressOutput:false, systemMessage:…). So the effective repro from our side is:

• Bare {"systemMessage": "…"} → flashes briefly, then the Line is discarded before it can be read/expanded
• Full schema {"continue": true, "suppressOutput": false, "systemMessage": "…"} → Line persists as expected

That reads less like a hard rendering regression and more like a silent tightening of Stop-hook output expectations in 2.1.114. If that's intentional, the docs should probably call it out — otherwise users emitting bare systemMessage (valid per the prior schema description) get transient flashes and no visible confirmation.

Not urgent from our side now that we've found the working shape. Flagging in case it matters for other plugins that were relying on the bare form.