Inline widget tool calls (mcp visualize show_widget) display as raw MCP tool-call arguments in a sibling split-off pane while rendering as a visual in the originating pane

What happened

In a Code-tab conversation split into two panes via Cmd-click on the sidebar (the gesture documented in #56278 / FACT-008), I called mcp_visualize__show_widget from the child window. The widget renders as a visual in the parent (originating) window. In the child window, expanding the same message's toggle reveals the raw MCP tool-call record — the literal title:, loading_messages:, and widget_code: arguments as plain text — followed by the harness's tool-result line ("Content rendered and shown to the user. Please do not duplicate the shown content in text because it's already visually represented."), not the rendered visual. That tool-result line is internal model-facing text and shouldn't be visible to the user at all; its leakage is a secondary symptom of the same defect. Both panes are viewing the same conversation message; only the parent applies the widget renderer. Switching window focus does not change either pane's behavior — no refresh, scroll, or reload needed or useful.

Why it matters

The Cmd-click split is presented as two views onto one conversation. If MCP-emitted rich content (widgets, images, embedded UIs) renders in only one pane while the other shows the raw tool record, the multi-pane workflow silently loses visual context — and exposes model-facing internal text — whenever the user happens to have focused the "wrong" pane. In my session, the model and I went around in a confused round-trip ("Where is the image?") because the visible pane was missing content the model knew it had produced.

Expected

Widget rendering should be a property of the message (and therefore the conversation), not of the pane that was focused when the tool call resolved. Both panes of the same conversation should apply the same renderer and show the same payload. Internal model-facing text in the tool result ("Content rendered and shown to the user…") should never be user-visible.

Reproduction

1. Open any conversation in a Code-tab session.
2. Cmd-click that conversation in the sidebar to split it into two panes within the same window (the gesture in #56278).
3. From the child pane, ask the model to invoke mcp__visualize__show_widget (or any MCP tool that returns an inline widget).
4. Observe: the widget renders as a visual in the parent window. In the child window, expanding the widget toggle for that same message reveals the raw MCP tool-call record — title:, loading_messages:, widget_code: as plain text — followed by the harness's tool-result line ("Content rendered and shown to the user. Please do not duplicate the shown content in text because it's already visually represented.").
5. Switching window focus between the two panes does not cause the child to re-render. Nothing — refresh, scroll, reload — changes either pane's behavior.

Likely cause (hypothesis)

Looks like widget-renderer registrations for MCP tools (here mcp__visualize__show_widget) are scoped per-window-instance rather than per-conversation, and the registration is not propagated to a child window when one is split off via the sidebar Cmd-click gesture. The child window's display layer treats the tool call as if no special renderer existed and falls through to its generic "tool call arguments + result text" plain-text view — which is why the harness's internal model-facing text becomes user-visible only in the child.

Environment

• Claude.app, Code tab on macOS Darwin 24.6.0
• Models tested: claude-fable-5[1m] and claude-opus-4-7[1m] (same behavior)
• MCP server: visualize (the Imagine suite — mcp__visualize__show_widget)

Related

• #56278 — the underlying Cmd-click split gesture itself was undocumented; this issue is an invariant gap in the feature surfaced by that gesture.