[Bug]: Host-path images show "Image unavailable" ("moved or deleted") when the session lacks filesystem:read, e.g. after redeeming a pre-upgrade pairing link #17906

Activity

1. Ultraman287 commented on Oct 10, 2026

   

   Ultraman287

   on Oct 10, 2026

   Author

   More actions

   Update: found the cause. It's a permissions problem, not image rendering.

   The Windows app's session was created by redeeming a pairing link that the 0.0.45 server minted shortly before the host was upgraded to the 0.0.46 nightly. That session got the legacy scope set (orchestration:read orchestration:operate terminal:operate review:write relay:read), so it had no filesystem:read.

   On web/desktop, useAssetUrlState / useAssetUrls (apps/web/src/assets/assetUrls.ts) skip media-file resources when useFilesystemReadAccess returns false. So the image never gets an asset URL, the client never requests it, and the UI shows the generic "Image unavailable. The file may have been moved or deleted." Android rendered the same images because its session came from a link minted by the new server, so it has the full standard scopes. (Another Android session made from a pre-upgrade link also got legacy scopes and never managed to connect.)

   Fix on my side: pair again with a link minted by the new server. With filesystem:read, every host-path image renders on Windows.

   So the original report is wrong as written. What's left to suggest:

   1. When file access is the reason, show something like "This connection doesn't have file access. Pair again to view host images" instead of "may have been moved or deleted". (PermissionUpdateNotice might have covered this, but if so it was easy to miss.)
   2. Pairing links minted by a pre-granular server and redeemed after the upgrade quietly produce legacy-scope sessions. It might be worth flagging these at redemption time.

   I've retitled the issue to match. Feel free to close it if (1) and (2) are already tracked.
2. Ultraman287

   changed the title [-][Bug]: Windows desktop shows "Image unavailable" for every host-path Markdown image from a remote macOS host (Android renders them)[/-] [+][Bug]: Host-path images show "Image unavailable" ("moved or deleted") when the session lacks filesystem:read, e.g. after redeeming a pre-upgrade pairing link[/+] on Oct 10, 2026
3. juliusmarminge commented on Oct 10, 2026

   

   juliusmarminge

   on Oct 10, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Thanks for the detailed report. The control image and the "no asset errors on the host" detail narrow this down a lot.

   What I checked on main (read-only):

   • The path parsing isn't the problem. classifyMarkdownImageSource (packages/client-runtime/src/markdownImages.ts) turns absolute POSIX paths, file:///Users/..., and angle-bracket paths into a media-file resource without any Windows-specific rewriting. Relative paths join the thread's workspace root. (Small aside: ~/... paths are blocked on purpose, so that variant won't render anywhere.)
   • Before asking the host for a signed URL, the desktop/web client checks whether this connection has the filesystem:read permission (useAssetUrlState in apps/web/src/assets/assetUrls.ts). If the session doesn't grant it, the client goes straight to Failure without sending assets.createUrl, and the image shows "Image unavailable". That fits what you're seeing: every host-path variant fails, HTTPS images still render, and the host logs nothing.
   • That check is new since 0.0.45. feat(auth): separate filesystem read and write permissions #9788 split filesystem read/write into separate permissions, and per packages/contracts/src/auth.ts, servers "never expand stored grants". So a remote pairing created before granular permissions may be missing filesystem:read, even though the old broad grant used to cover asset URLs. fix(auth): keep old clients connected across scope changes #10298 keeps those old clients connected and shows a permission-update notice, but it doesn't add the permission.
   • I didn't find a remote base-URL mixup. The signed URL is resolved against the remote connection's httpBaseUrl, and the desktop CSP allows https: images. The desktop's local-media fallback (fix(desktop): resolve local media linked from remote threads #10619) only runs after the host returns a not-found error, so it doesn't apply here.

   I haven't reproduced this, so the permission theory is unconfirmed. Android working on the same host would be consistent with it if that phone was paired more recently, or with a grant that includes file access.

   Could you check:

   1. On Windows, does the Files tab (or file search with @) work for this host? If it's blocked too, it's almost certainly the permission.
   2. Do you see a "permissions updated" or re-pair notice for this environment?
   3. Does removing and re-pairing the Windows app with file read access fix it?

   Related: #17668 (same symptom on iPhone, likely the same permission check), #10322, and #14261 / #14839 (Windows backslash paths, which don't apply here).
4. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   on Oct 10, 2026