Repository navigation
Media embeds don't render when the file path contains a space (agents aren't told to wrap paths in <…>) #26685
Description
What happened
On Windows, when the user's home folder name contains a space, agents embed screenshots and videos using a path that is not wrapped, so the chat shows the raw text instead of the media:
This happens every time an agent sends media from a file under the home folder.
Diagnosis
In CommonMark, a link destination ends at the first space unless it is wrapped in <…>. Because of this, the line above never becomes an image node, so ChatMarkdown's img handler never runs.
The renderer already handles the wrapped form: ChatMarkdown.browser.test.tsx renders . The gap is in the instruction given to agents in packages/provider-core/src/server/runtimeInstructions.ts:
You can embed images, video, and audio in your response using Markdown image syntax with absolute file paths.
The instruction says nothing about paths that contain spaces, so agents write bare paths. Every Windows user whose username contains a space hits this, as does anyone whose files live under a folder name with a space.
Possible fixes, in order of effort:
- Add to the runtime instruction: "wrap the path in
<…>(e.g.)". - Before parsing, make the chat recover
when the destination is an unwrapped absolute path that exists.
Steps to reproduce
- On Windows, use an account whose user folder contains a space (e.g.
C:\Users\First Last). - In any Claude thread, ask the agent to take a screenshot or record a video and show it in chat.
- The agent writes
, and the message shows that literal text with no media. - Ask the agent to resend it as
, and the media renders.
Version
0.1.4-nightly.20261028.3841 (desktop app and local server; commit 9e09926)
Environment
Windows 10 Pro 10.0.19045, x64, Node v24.22.0. Claude Code harness, Opus 5.5.
Evidence
Screenshot of the unrendered message (attached below). The message text is the literal  followed by a File: [walkthrough.mp4](…) link that also failed to render.
Related issues
None found. Searched for "spaces path image markdown" and "windows path space media not rendering".
Fix applied or workaround
Ask the agent to wrap media paths in <…>.
Filed by
Claude Code (Opus 5.5, claude-opus-5-5) via the T3 Code triage playbook.
Activity
kirbysama commentedon Nov 3, 2026
Same bug on 0.1.6 (Windows desktop app with local server, Windows 10 Education 10.0.19045 x64, Claude Code with Opus 5.5). It has happened on every version since 0.0.45.
One more symptom worth adding: once the line falls back to text, CommonMark drops the backslash before any punctuation in the path. The user sees
with
\.t3collapsed to.t3. That makes it look as if the agent wrote a bad path.remarkKeepWindowsPaths(packages/shared/src/markdownWindowsPaths.ts) doesn't help here. Its prose regexUNFINISHED_DRIVE_PATH(/(?:^|\W)[A-Za-z]:(?:[\/]\S*)?$/) stops at the first space, so the escape in\.t3is decoded anyway. The current tests only use space-free paths likeC:\Users\me\.t3.Wrapping the path in
<…>renders correctly. #27970 looks like it would fix both symptoms, and a test with a space plus a\.-prefixed folder would be useful there.Added by Claude Code (Opus 5.5,
claude-opus-5-5) via the T3 Code triage playbook.doolecg commentedon Nov 11, 2026
Still happens on 0.1.9-nightly.20261110.4465 (Windows 11 Pro, desktop app, Claude provider). The release notes for 0.1.9-nightly.20261111.4515 don't mention a fix, and I haven't tested that build.
It is not limited to the user home folder. A project folder with a space is enough.
Steps:
E:\REPOS\My Game..!, and no image.A path without a space renders fine. Rewriting the destination as
<E:/My Game/shots/a.png>should render, as in the issue description; I haven't tested that in the app.I also have a small renderer-side patch for the second suggested fix (wrap spaced media destinations in
<...>before parsing, skipping code spans and fences). It is untested so far, so I won't open a PR unless you want one.andresaclan commentedon Nov 12, 2026
Same bug on 0.1.8 (Windows desktop app with a local server running in WSL2, Claude Code with Opus 5.5). This bug is not limited to Windows paths: a Linux path through
/mnt/cwith a space in one folder name breaks the same way.The agent's reply contained:
The chat showed that line as literal text, including the
!, and no image. The file exists at that path. When I resent the same paths wrapped as, both images rendered, so the renderer handles the wrapped form fine on WSL.A plain file link in the same message,
[editor_window.png](/mnt/c/.../<folder with space>/.../editor_window.png), also showed as plain text with nothing to click. #17742 (closed) fixed file links with spaces in the path, but that fix didn't cover this one: an absolute/mnt/c/...path on 0.1.8.I checked the source: the instruction in
packages/provider-core/src/server/runtimeInstructions.tsstill says only "using Markdown image syntax with absolute file paths", both atv0.1.8and onmaintoday. So agents keep writing unwrapped paths, and this isn't fixed in the 0.1.10 previews.Workaround: add a line to the project's
CLAUDE.md/AGENTS.mdtelling the agent to wrap media paths in<…>.Triaged with Claude Code (Opus 5.5) via T3 Code triage.