Terminal: no inline images, clickable text not consistently marked, and markdown links with schemeless paths fail to open (-50)

Feature requests: inline images, and consistent link affordance

Three requests and one bug, all found while testing how the terminal renders
links and images. Tested in iTerm2 on macOS (Darwin 25.6.0).

---

1. BUG: markdown link with a schemeless absolute path fails to open

[text](/Users/me/file.png) renders as a proper link, underlined and colored,
but clicking it produces a Finder dialog reading "The application can't be
opened. -50". -50 is paramErr.

The href is being handed to the OS opener as a URL. A leading slash with no
scheme is not a URL, so it is rejected before Finder ever resolves a file. The
same path written as [text](file:///Users/me/file.png) works correctly.

Suggested fix: normalize a schemeless absolute path to file:// before
handing it to the opener, or fall back to path resolution when URL parsing
fails.

This matters because a schemeless path is the form an assistant writes by
default, and the link looks completely legitimate until it is clicked.

---

2. Clickable text is not consistently marked as clickable

A bare path in prose is clickable via option-click, but renders in the default
text color, visually identical to the words around it. A backticked path is
clickable and renders blue. So color does not track clickability in either
direction, and there is no way to tell by looking whether something can be
clicked.

Observed rendering, all in the same message:

| Form | Clickable | Rendered as |
|---|---|---|
| bare /abs/path.png | yes, option-click | default text color, no marking |
| ` /abs/path.png | yes | blue |
| [text](/abs/path.png) | no, -50 | colored + underlined |
| [text](file:///abs/path.png)` | yes | colored + underlined |

The practical cost: an assistant hands over something to click, and the user
cannot tell it is clickable, so they miss it. Or the opposite, a link is styled
like a link and turns out to be broken (row 3).

Request: one consistent visual treatment for anything clickable, applied to
every clickable form. If a bare path is going to be option-clickable, it should
look clickable too.

---

3. Render images inline in the terminal

There is currently no way to display an image. Markdown image syntax degrades to
a link in every form tested, local absolute path, tilde path, and remote URL.
None embed.

Two independent halves. The first is cheaper and higher value.

3a. Thumbnail the images the user attaches

When a screenshot is dropped into the prompt, the assistant receives the decoded
image and the user sees a [Image #1] placeholder. The file is already in hand
and already decoded, so the asymmetry is the surprising part. A small inline
thumbnail in the user's own transcript would confirm the right file was attached
and give the scrollback a visual anchor.

This is the common case. We attach screenshots constantly.

3b. Thumbnail images the assistant references

When the assistant points at an image on disk or at a remote URL, render it
inline rather than as a link. Needs more design than 3a:

• A max-width clamp, and a max-height clamp too, since a full-page screenshot

would otherwise eat the scrollback.

• Click-to-expand, either to full size in the terminal or handed off to the

default viewer.

Why the assistant cannot work around this

iTerm2 has an inline image protocol and ships imgcat at
/Applications/iTerm.app/Contents/Resources/utilities/imgcat, but it is not
reachable from inside a Claude Code session:

• Bash tool output is a captured pipe, not a tty. tty returns not a tty and

TERM_PROGRAM is unset, so the OSC 1337 escape sequence would arrive as
literal bytes in a tool result rather than being interpreted by the terminal.

• Both $PPID and its parent report a tty of ??, so there is no controlling

terminal to write to.

• Writing to a guessed /dev/ttysNNN would fight the TUI's own redraw and

garble the screen, and would still be a guess.

So this has to come from the renderer.

---

Note on filenames, relevant to all of the above

macOS screenshot filenames contain a narrow no-break space (U+202F) before
AM/PM, not a regular space. Example, as raw bytes:

Screenshot 2026-08-17 at 3.07.51<U+202F>PM.png

Backticked paths handle this correctly. A file:// URL needs it percent-encoded
as %E2%80%AF. Worth confirming any path handling in the renderer is
byte-accurate rather than assuming ASCII spaces, since this is the single most
common filename users will paste or click.

---

Environment

• Claude Code in iTerm2, macOS (Darwin 25.6.0)
• Model: Opus 5 (1M context)
• iTerm2 configured to require option-click to follow links

---

Related existing issues

Neither of these covers the terminal surface, but they are adjacent:

• #39879 (closed) - configurable image thumbnail size, VS Code extension
• #63204 (closed) - GUI: dispatch file:// and custom-scheme clicks to OS shell handler

Item 1 below is the terminal counterpart to #63204.