GitHub Issue

MessageDisplay block never renders in interactive TUI — upstream Claude Code bug (anthropics/claude-code#85773)

Discovered On Aug 11, 2026

Primary Metric open

## The plugin is correct — it's blocked by an upstream Claude Code bug Heads-up that `claudish-to-english`'s `MessageDisplay` block never appears in the interactive TUI on Claude Code **2.1.227**, and it's **not a plugin bug** — the hook does everything right. I filed the upstream issue here: **anthropics/claude-code#85773** — https://github.com/anthropics/claude-code/issues/85773 ## What I verified Running with `CLAUDISH_STUB=1 CLAUDISH_DEBUG=1` (deterministic stub, ollama out of the loop, ~zero latency): - The hook fires per chunk, buffers, and on the final chunk emits well-formed `{"hookSpecificOutput":{"hookEventName":"MessageDisplay","displayContent":...}}`, exit 0. Debug log confirms `stub rewrite` on every qualifying message (single-chunk and multi-chunk). - Claude Code's **core honors it in `--print`**: `claude -p` with the stub puts the `STUB-SIMPLIFIED` marker in stdout. - But **every interactive renderer drops it** — fullscreen (in a Ghostty terminal and in plain Terminal.app) and screen-reader plain-text mode (`CLAUDE_AX_SCREEN_READER=1`). No block on screen, no error, `/plugin` Errors tab empty. - The `MessageDisplay` + `displayContent` feature shipped in Claude Code 2.1.152, so it is present in 2.1.227. ## Why this is for your awareness Nothing in the plugin needs changing to fix the rendering — it's an interactive display-path gap in Claude Code. Until that's fixed, the appended block only shows in non-interactive `--print`. You may want to note this in ...

View Raw Thread

Developer & User Discourse

gvzdv • Aug 11, 2026

Thanks for the detailed writeup! I tried to reproduce this on the same version (Claude Code **2.1.227**) and haven't been able to — in the normal interactive TUI (plain `claude`, no `-p`), the `💬 In plain English:` block renders correctly for me.

Terminals I tested, all rendering correctly:

- **iTerm2**
- **VS Code integrated terminal**

One thing I want to mention: the rewritten block shows up with a **slight delay**, *after* the local model has finished processing. That's expected — the display hook buffers every streamed chunk and only calls ollama on the **final** chunk, so the block can't appear until the whole message is known and the model has produced the rewrite. On a cold model or a long message that gap can be several seconds, during which only the original text is on screen.

Since I can't reproduce the "never renders" case, could you help me narrow the trigger? A few specifics would help a lot:

1. **Terminal + fullscreen** — you mentioned Ghostty and Terminal.app. Which...

zyvz • Aug 11, 2026

Another data point — I see different behavior from you on what looks like a similar setup, so this may help narrow it.

**Setup:** Claude Code 2.1.227 (native binary install), macOS (Darwin 25.5.0), iTerm2 3.6.10, standard fullscreen TUI renderer. Plugin v0.1.1, `CLAUDISH_MODE=append`.

The interactive TUI never paints the block for me, even though the hook fires and emits fine. Quick answers to your questions:

- **Mode:** `append` (default).
- **MIN_CHARS:** I ruled it out — same result with `CLAUDISH_MIN_CHARS=10` and with the 200 default, on replies well over the threshold.
- **Debug log** (`CLAUDISH_STUB=1 CLAUDISH_DEBUG=1`): the final chunk logs a clean emit every time, e.g. `final: prose_len=603 min=10 mode=append full_bytes=704` then `stub rewrite`. Exit 0, no fail-open.

The stub also removes model latency from the picture. To isolate hook from renderer: `claude -p` shows the `STUB-SIMPLIFIED` block in stdout (stub, and the real plugin), but the interactive TUI never shows it....