fix(web): copying an image with a spaced path keeps it an image #35914

markdownImageCopy (apps/web/src/components/chat/ChatMarkdownMedia.tsx) wrote the image path into the copied Markdown as-is. Raw HTML and sources reach it with a literal space, so the copied text did not parse as an image. A new markdownDestination helper leaves the path unchanged unless it contains whitespace, '<', '>', '(' or ')'. In that case it uses CommonMark's angle-bracket form: backslashes, '<' and '>' are escaped and CR/LF become %0D/%0A, since an angle-bracket destination cannot contain a line break. The result is e.g. ![Shot](</work/my shot.png>). Ordinary paths copy exactly as before. I checked with remark-parse that spaced, Windows, parenthesised, <>-containing, newline-containing and plain paths all parse back to one image with the intended URL. Regex worst case: a single character-class test /[\s<>()]/, linear in the path length, no backtracking. The repro test from factory/repro-35889 is kept. Its assertion is unchanged, but I narrowed its node traversal to the parsed paragraph because the original flatMap failed typecheck (TS2322/TS18046). That edit is in the fix commit.

Fixes pingdotgg/t3code#35889

Reproduction on main#

Commit 95cb068c10 (origin/main). Ran T3CODE_DEV_SEED=0 vp run dev with a scratch, uncommitted Replay (dev) scenario whose reply contained four image forms pointing at a real 'my shot.png' in a git project: ![Plain](</…/my shot.png>), a Windows path in angle brackets, a raw HTML <img src="/…/my shot.png">, and a <picture> with a spaced srcset and src. Created the thread with node apps/server/src/bin.ts thread start --provider devReplay, opened it in headless Chromium (playwright-core) after pairing, selected the whole reply and ran a real copy, reading event.clipboardData in a window copy listener after the app's handler. Result: the reporter's exact form copied as ![Plain](/…/my%20shot.png), which is still a valid image because the space arrives percent-encoded, so their script's direct helper call overstates that case. The HTML and images, which rendered fine, copied as ![Html](/…/my shot.png) and ![Pic](/…/my shot.png), which parse to no image node with remark-parse. A failing unit test was added and pushed.

Evidence#

Replayed the same synthetic reply in the real web app on both commits, waited for its images to render, selected the reply, and pressed Ctrl+C. The inspector shows the actual clipboard text and its remark-parse result; only the temporary workspace prefix is replaced with /work/demo. Chromium, 1280×800, light theme, fresh databases, Replay (dev).

Evidence	Before — 95cb068c10	After — ba19d2ec9f
Result	HTML img and picture copy as bare spaced destinations; neither parses as an image.	Both copy with angle-bracket destinations and preserve the file reference.
Rendered reply
Clipboard
Recording	Before copy interaction	After copy interaction

The angle-bracket Markdown control remains valid on both commits. scenarios:prove exited 0.

Scenario source

Not shown:

• Windows filesystem paths were not exercised; this proof covers real local Linux paths with spaces.

Tests#

vp test run src/components/chat/ChatMarkdownMedia.browser.test.tsx -t markdownImageCopy: failed before the fix and passed after (2/2 in the file). vp run check:changed: format, lint, knip, typecheck (2 packages), test (1 file) and react compiler all pass. Before the test typing fix, typecheck failed on the repro test. A scratch remark-parse check of 6 path forms all parsed as images.

Not in this change#

• markdownImageCopy's existing escaping of alt text and title was not changed.

Who did the work#

• Written by Claude Opus 5.5, in Claude Code
• Reviewed by GPT-6.1 Sol, in Codex, and by Claude Opus 5.5, each on its own
• Proof captured by GPT-6.1 Sol and checked by Claude Opus 5.5

Run by the t3code factory in T3 Code.