Repository navigation
Android host-path Markdown image is blank while desktop and HTTPS embeds work #10322
Description
Activity
Triage
Confirmed as a new Android bug, not a re-open of #9094. Desktop rendering plus a working HTTPS control isolate this to host-path Markdown → signed environment asset → Android image view, not “PNG is bad” or “Android cannot show images.”
What the clients do today
is classified as a host file (packages/client-runtime/src/markdownImages.ts; angle brackets are stripped). Current main asks for amedia-filesigned URL (#9023,apps/server/src/assets/AssetAccess.ts). That grant is allowed: projects are not a filesystem sandbox (docs/internals/environment-auth.md). Desktop chat uses the same resource viaChatMarkdownAssetImageand paints.Android chat goes through
ThreadFeed.renderMarkdownImage→ThreadMarkdownImage(apps/mobile/src/features/threads/). The tile uses React NativeImageat opacity 0 untilonLoad.#10199sizes that tile from the server header (this fixture is 1800×2600), so a failed or hung decode looks like a large blank rather than a missing node. IfrenderImagereturns null,NativeMarkdownImageloads the raw host path as a URI — another empty rounded box with no error.Store 1.0.3 may still be on the older
#6433workspace-filerequest, which cannot authorize a path outside the project. That should show “Image unavailable”; a silent loading/fallback box would match this report. The 1.0.4 emulator in-project copy does not answer the phone case (different version and path scope).HTTPS works because it is
Directand never hits the host-file signer.Related: #9023 (host media), #6433 (workspace images), #8779 (Android markdown renderer), #10199 (frame-before-bytes), open #9087 (iPhone empty gray boxes — similar loader, different platform).
Suggested check (before a fix PR)
On 1.0.4 / current, same thread, same absolute dest (not an in-project copy):
- Does the host-path image paint?
- Does an in-project relative embed paint on that same phone?
- Does a tiny PNG at the same absolute path paint (rules out the 5 MB / tall decode)?
If current still blanks: keep the signed
media-fileURL, make the Android tile use a loader that reports failure (expo-imageis already the #9087 direction), and never leave a reserved frame with no image and no “Image unavailable.”Not
duplicate/invalid/wontfix. HTTPS hosting remains a workaround.Retested on the same phone with Android 1.0.4 built from
d924fe266. The original image now renders in its original thread and message. The absolute-path embed, identical in-project relative copy, and tiny PNG at a separate outside-project path also render. I can no longer reproduce this on the current build.Could you publish a new Google Play release too, so we can get these fixes without sideloading?
Note: GPT-6 on behalf of Shivam (@shivamhwp).
Closing based on your successful retest on the same Android phone using 1.0.4 at d924fe2. The original image and thread, an in-project relative copy, and a tiny image outside the project all rendered. Google Play rollout is a separate follow-up; this closure reflects the confirmed fix in that tested build.
- linked a pull request that will close this issuefix(server): answer requests that arrive before the HTTP handler attaches #12291
on Sep 18, 2026
Environment
Reproduction
Emitted Markdown, with the private path replaced by an equivalent example:
The tested file is a valid 1800 × 2600 PNG, 5,008,501 bytes.
Observed
Expected: the authorized host-path image renders on Android too, or a visible error explains why it cannot be loaded.
The HTTPS embed is a verified workaround for this image, but requires separately hosting it. The exact failure layer is unknown. An Android 1.0.4 emulator rendered an in-project copy, so that test differs in both client version and path scope and does not establish a regression or fix for the phone case.
Related: #9094 was closed after the local-path and native-image fixes, with a request to open a new issue for remaining failures. This report concerns a host-path Markdown image on Android, not a data URI or HTML image.