[FEATURE][CLI] Markdown renderer support in Claude Code CLI

I second this. This enhances readability of Claude cli output

Third, and adding a specific use case: GitHub PR templates with checkbox syntax (- [ ]) currently render as plain list items with the brackets stripped. This makes checklists unreadable when editing or reviewing PR templates in Claude Code.

I think a really good alternative solution would be letting it use CLI tools. For instance, instead of Claude's own, because maybe you have Mermaid or some other stuff supported, just any CLI Markdown rendering would be ideal.
A config option to use Glow, or a custom one provided it has similar or identical configurations to some kind of contract.
Kinda like how they added VI editing.

Just ran into this - the Claude Code docs (or some error message) suggested adding "renderMarkdown": false to settings.json, but that setting doesn't actually exist in the schema. The edit fails with a validation error.

Would love to see proper markdown rendering support, or at minimum a toggle to control it. Currently the raw markdown syntax makes output harder to scan quickly.

Adding a real-world use case: I have onboarding commands that display GitHub issue links using [Issue #954: title](https://github.com/...) syntax. In the terminal:

1. The markdown link doesn't render — shows raw [text](url) syntax
2. Worse: when link text contains #N (e.g., [#954](...)), the OSC 8 hyperlink rewrites the URL to the current git repo's issue tracker instead of the specified URL (see #29188)

This means every issue reference in my CLI output either shows as raw markdown or links to the wrong place. Plain URLs auto-linkify fine, but you lose the descriptive text.

Would love to see at minimum the OSC 8 autolink bug fixed so explicit [text](url) links respect the provided URL.

+1 to this, adding a pain point from my claude code sessions:

Summary

URLs output by Claude Code (e.g. after git push, PR creation, or any GitHub operation) are not clickable in the output pane. Users must manually copy-paste them.

What was tried

• Markdown links [text](url) — renders as styled text but has no click handler
• Plain URLs — rendered with a code-block background; iTerm2 URL auto-detection doesn't work inside Claude Code's rendered UI layer
• Inline code — same result

Root cause

Claude Code renders output in a custom UI pane, not as raw terminal characters. Terminal emulators like iTerm2 can only auto-detect URLs in raw character streams, not in
a rendered UI layer. No text format Claude can output will produce a clickable link today.

Suggested fixes

1. OSC 8 hyperlink escape sequences — supported by iTerm2, Wezterm, Kitty, and most modern terminals
2. Native click handling in the UI renderer — wire markdown links or bare URLs to open in the system browser on click
3. Cmd+click support — at minimum, standard macOS convention for URLs

Impact

Any workflow involving URLs (branch links, PRs, files after a push) requires manual copy-paste. This is a very frequent operation in git workflows.

Adding a concrete observation that strengthens this request:

Plan mode already has capable markdown rendering. When Claude Code enters plan mode (/plan) and displays the plan file, tables render with aligned columns, headings show visual hierarchy, bold/italic are styled, code blocks get formatting, and lists render properly. I tested this by writing a plan file containing every common GFM feature (tables, nested lists, code blocks, blockquotes, checkboxes, headings h1-h4, bold/italic/strikethrough, horizontal rules) and the plan display rendered all of them well.

The rendering engine exists. It just isn't wired to the main response output stream. The system prompt already tells the model to use GFM ("You can use Github-flavored markdown for formatting"), so the model produces markdown that the plan renderer can handle — it's only the response stream that shows raw syntax.

This seems like a routing issue rather than a capability gap. The question isn't "build a markdown renderer" — it's "apply the existing plan renderer to response output."

Edit: damn, giving claude permission to use the gh cli can be a dangerous thing, even if it's just for a short duration. lesson learned.

i guess claude _really_ wants to render markdown.

Edit 2: to be fair it is a useful observation, planning mode does seem to be rendering markdown already. it did however also state that "It's probably a one-line change somewhere" in our discussion, so i won't speak for the accuracy of the details.

+1

+1

+1

+1, and the key insight buried in this thread: plan mode ALREADY renders
markdown (tables, headings, code blocks, lists) correctly. So the renderer
exists and is wired into one code path but not the main REPL output — this
is a routing/integration task, not build-from-scratch. Landing it also
unblocks Mermaid (#14375) and any future chart output via the #64643
passthrough. The whole visualization stack is one renderer + one hook away.