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=1exported and"tui": "fullscreen"in settings.json). Not yet tested whether the classic renderer is also affected. TERM=xterm-256color,COLORTERM=truecolor,NO_COLORunset
Reproduction
- Start Claude Code with the fullscreen renderer.
- Have the assistant emit a message containing bare inline triple backticks in running text, in two separate list items, e.g.:
```markdowninline code`)**
**Control zone A — tame markdown (bold,
- 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.
- Test item two — scroll up and look for a lone ```.
Control zone B — tame markdown after the test
````
- 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 fencedbash` 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…'Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
A/B result: with the classic renderer (
CLAUDE_CODE_NO_FLICKER=0, same binary 2.1.198, same WezTerm/macOS 26 setup) the exact same repro content renders correctly — bold/lists/inline code styled, the bare inline ``` shown literally without breaking the rest of the message. Only the fullscreen renderer exhibits the whole-message raw fallback.Update after a 2-week controlled experiment — the bug is not fullscreen-specific, and I now have hard terminal-buffer evidence.
1. Reproduces on the default (non-fullscreen) renderer. On 2026-08-03 I removed
CLAUDE_CODE_NO_FLICKER=1from my shell config (settings.jsonhas"tui": "default"), so every new session since ran the classic renderer. The raw-markdown incidents continued at the same frequency (~every 3rd–4th session). The title's "fullscreen renderer" scoping is wrong — the fallback lives in the shared markdown pipeline.2. The trigger is broader than bare triple backticks. Two confirmed incidents where the affected message contains zero triple backticks and a balanced count of inline backticks (one on 2.1.220, one on 2.1.233).
3. Hard evidence: zero ANSI codes in the terminal's own cell buffer. Captured a live incident on 2.1.233 (default renderer, macOS 26, WezTerm) via
wezterm cli get-text --escapesfrom a healthy pane:**bold**, list markers, etc.) contain no ESC/SGR sequences at all in the terminal cell buffer.So Claude Code emitted the message as unrendered plain text — this is client-side, the terminal emulator is definitively not involved (also observed identically in Ghostty earlier).
Environment across incidents: macOS 26, WezTerm, long-lived sessions, typically 12+ concurrent sessions. Versions 2.1.198 → 2.1.233, both renderers.
Happy to provide the full escape-sequence pane captures — I now have an automated watchdog saving them at incident time.
Root cause found — and it is neither the triple backticks nor the fullscreen renderer this issue was originally scoped to.
Claude Code decides markdown-vs-plain by scanning only the first ~500 characters of a message: if the first markdown construct starts at offset ≥500, the entire message is displayed as raw source. Deterministic, renderer-independent, exact boundary bisected (499 renders / 500 raw), with a one-paragraph repro.
Full report with repro and evidence: #87185. My earlier analyses in this thread (backtick trigger, fullscreen scoping, concurrent-session theories) are superseded by it.
Thanks for the detailed report and repro steps. I tried to reproduce this on 2.1.233 (and also on your reported 2.1.198) on Linux in tmux, using the fullscreen renderer (
CLAUDE_CODE_NO_FLICKER=1+"tui": "fullscreen") and your exact sample message —**bold**, a[link](url), a stray ``mid-sentence, then## Done`.In both versions the message rendered fully formatted: bold was styled, the link was a real hyperlink, and the heading was styled — no whole-message fallback to raw markdown. So I can't reproduce this as described.
One likely explanation: when asked to "reply with exactly this text", the model often wraps the whole reply in an enclosing code fence — and everything inside a fence (including text before the stray backticks) correctly renders as literal markdown source. A ``
Could you share:
/export), so we can see whether it's wrapped in a fence,Happy to dig further with that info!
🤖 Generated with Claude Code
We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.