Long assistant responses (markdown tables / code blocks / file links) silently fail to render in VSCode extension

Environment

• Client: Claude Code VSCode extension (native)
• OS: macOS (Darwin 23.6.0)
• Model: claude-opus-4-7 (1M context)

Symptom

Long assistant responses containing markdown tables, fenced code blocks, and file path links never appear in the chat panel. The "Thinking..." indicator shows briefly, then disappears without rendering any text. The next user message can be sent normally, as if the assistant produced no reply.

Short plain-text responses (< ~30 chars, no markdown) render correctly in the same session.

Repro (intermittent but reliable in long sessions)

1. Start a session that mixes substantive Q&A with file exploration tools (Bash, Read).
2. After several turns, ask a question that triggers a long markdown response with: a table, two or more fenced code blocks, multiple [filename.ts:42](path#L42) style links.
3. Observe: assistant turn ends with no visible text output.

Correlation observed

• Failures cluster around turns where system-reminder messages about MCP server disconnect/reconnect are injected.
• The assistant's own logs show the long response was generated; only client-side rendering drops it.

Hypothesis

Streaming parser / tag boundary handling — likely <thinking> or tool_use block close events are being misinterpreted, causing the trailing <text> content to be discarded. The correlation with MCP disconnect events suggests the parser may be entering a bad state when reminder blocks arrive mid-stream.

Impact

Conversations become unrecoverable: the model believes it has answered while the user sees nothing, leading to repeated "you didn't answer" cycles. Workaround (forcing very short plain-text replies) defeats the tool's purpose.

Logs

The Claude Code Output panel log can be attached on request if it captures parser errors.