[Bug]: File links whose path contains a space render as plain text #17742

Before submitting

• I searched existing issues and found related reports, but this is a distinct case.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Have an assistant reply contain a Markdown link to a local file whose path has a space in it, with a bare (unbracketed) destination, for example:

   [message](path/to a spaced repo/file)
   [AGENTS.md](C:/Users/me/Main Projects/repo/AGENTS.md)

2. Look at the rendered message and try to click the link.

Expected behavior

The link renders as a clickable file link and opens the file, the same as a path without spaces does.

Actual behavior

The whole thing renders as plain text ([message](path/to a spaced repo/file)), with nothing to click.

The same path without spaces works, and the angle-bracket form [message](<path/to a spaced repo/file>) also works.

Notes

Strictly, CommonMark doesn't allow spaces in a bare link destination, so the parser is following the spec. But agents write local paths this way all the time, and on Windows a space in the path is common (My Projects, Program Files, OneDrive folders), so every file link in a project like that comes out as plain text.

This looks like the same kind of render-time repair proposed in #11810 (closing a missing >): when [label](...) has a destination that contains spaces, has no ) inside it, and looks like a local file or folder path (relative, ./, /, or a Windows drive path), treat it as if it had been written [label](<...>). Web URLs and well-formed links would be left alone.

Related, not duplicates: #11810 (unclosed <), #5158 (angle-bracket destinations), #16096 (non-ASCII relative paths), #15237 (trailing-slash folders).

Environment

• T3 Code 0.0.46-nightly.20261007.2787
• Windows 11 x64
• Provider: Claude Code