Bare inline triple backticks in a message make the fullscreen renderer display the ENTIRE message as raw markdown (2.1.198, macOS, WezTerm)

Description

When an assistant message contains a bare triple-backtick sequence mid-sentence (not at a line start, i.e. not a valid fence opener), the terminal renderer falls back to displaying the entire message as raw markdown source: literal **bold**, backtick characters, raw [label](url) link syntax, unstyled headers. The fallback is whole-message — content before the offending construct also loses all formatting.

Messages without the construct render normally in the same session, including messages with well-formed fenced code blocks. Ctrl+O does not change the display.

This bites in practice whenever the assistant writes about markdown or code fences (e.g. explaining "look for a stray ``` fence"), so it may be the root cause behind other vague "markdown suddenly not rendered" reports.

Environment

• Claude Code 2.1.198 (native install, auto-updated 2026-07-01)
• macOS 26 (Darwin 25.2.0), WezTerm 20240203-110809
• Fullscreen renderer (CLAUDE_CODE_NO_FLICKER=1 exported and "tui": "fullscreen" in settings.json). Not yet tested whether the classic renderer is also affected.
• TERM=xterm-256color, COLORTERM=truecolor, NO_COLOR unset

Reproduction

1. Start Claude Code with the fullscreen renderer.
2. Have the assistant emit a message containing bare inline triple backticks in running text, in two separate list items, e.g.:

```markdown
**Control zone A — tame markdown (bold, inline code`)**

1. Test item one — if a response contains an odd number of ``` fences, everything after the stray fence renders as a literal code block, stars and all.
2. Test item two — scroll up and look for a lone ```.

Control zone B — tame markdown after the test

````

1. The whole message (including both control zones) is displayed as raw markdown.

Expected

Per CommonMark, a mid-line ``` is not a fence opener, and an unmatched backtick string renders literally. At worst the ambiguous span itself could render oddly — but the rest of the message (bold, lists, inline code, headers before/after) should keep normal styled rendering.

Actual

The entire message, first line to last, is displayed as unrendered markdown source (uniform unstyled text, literal **/backticks/link syntax). Subsequent messages without the construct render normally again.

Supporting evidence

Reproduced deterministically twice in one session:

• Message A contained the two bare inline ``` runs → rendered fully raw.
• Message B (minutes later, same session) contained exactly two `` runs but as a well-formed fenced bash` block → rendered perfectly.

Extracted raw text around the trigger from the session transcript (.jsonl):

'…an odd number of ``` fences, everything after the stray fence renders…'
'…scroll up and look for a lone ```.\n- Only in fresh sessions…'