Repository navigation
[Bug]: Windows image paths fail on mobile after Markdown renderer replacement #23722
Description
Before submitting
- Searched existing issues. Related report [Bug]: Images and file links with Windows paths like C:\Users\me\.t3\... don't load #14261 was closed as fixed; this report identifies the mobile regression after feat(mobile): replace custom Markdown rendering with Enriched #16979.
- Included reproduction steps, observed results, and the relevant renderer history.
Area
apps/mobile
Steps to reproduce
-
On a Windows host, create an accessible image at
C:\work\.t3\shot.png. -
Have an agent include both embeds in the same message:
 
-
Open the message on mobile.
The example path is generic. The observed reproduction used a different local path containing the same separator-before-dot-directory pattern.
Expected behavior
Both embeds display the same image, preserving the Windows-path compatibility previously provided by #12615.
Actual behavior
On the reporter's iPhone, the backslash version shows "Image unavailable", while the forward-slash version of the same existing file renders correctly in the same message.
Impact
Minor bug or occasional failure: agent-provided Windows image paths can fail on mobile.
Version or commit
- Running server:
0.1.2-nightly.20261022.3526. - Mobile client:
2.0.0; its User-Agent reports build122. - Source investigated:
3e250a838773062804ee362272e7cf1baf9a5f1c. This is the investigation checkout, not a claim that the installed client was built from that commit.
Environment
- Mobile: iPhone 15 Pro Max, iOS 27.0.1.
- Host: Windows 11 Enterprise 26H2, build 26300.9711, x64.
Logs or stack traces
No crash or stack trace is involved. Source investigation identified a regression:
- [Bug]: Images and file links with Windows paths like C:\Users\me\.t3\... don't load #14261 reported this Windows-path corruption; [Bug]: preview_snapshot returns raw Windows backslash path breaking chat image rendering (Image unavailable) #14839 was closed as its duplicate.
- fix(markdown): keep Windows paths intact in link and image destinations #12615 fixed both web and mobile. Mobile used
nativeMarkdownWithAuthoredWindowsPathsto restore authored destinations after parsing. - feat(mobile): replace custom Markdown rendering with Enriched #16979 replaced the custom mobile renderer with
react-native-enriched-markdown, deleting that helper and its regression tests without carrying the Windows-path handling into the replacement. Web retained its preservation hook.
Standard Markdown interprets \. as an escape, so the example destination becomes C:\work.t3\shot.png. This is lost T3 Code compatibility behavior, not necessarily a standards violation in the parser library.
Screenshots, recordings, or supporting files
Workaround
Use forward slashes for drive-letter paths. Do not blindly apply this to UNC paths: //server/share/... can be interpreted as a protocol-relative URL.
Activity
xszaryx commentedon Oct 24, 2026
Same failure on Android, with
\_instead of\..Host is Windows (T3 Code Nightly desktop as the server). Client is a Pixel 9 Pro XL running the mobile app built from
mainat 2c592a1. An assistant message contained:The file is inside the thread's workspace. The desktop app renders it. Mobile shows "Image unavailable" with the caption.
md4c resolves backslash escapes in link and image destinations (
md_build_attributewithoutMD_BUILD_ATTR_NO_ESCAPES), so the app receivesD:_projects_app\app\....classifyMarkdownImageSourcethen reads the leadingD:as a URI scheme and returnsBlocked. So any backslash before ASCII punctuation breaks the path (\_,\.,\-,\(and so on), not just dot-directories.The forward-slash,
file:///and workspace-relative forms of the same path don't go through that unescaping, so they classify as a workspace file.#23750 looks like it covers this case too.