Reproduced on main at b5a226e49c: Linux host, real web dev client in Chromium, isolated copied state. Paired with only orchestration:read and orchestration:operate, then rendered an assistant host-video reference alongside a host image. The video shows “Video unavailable · Demo” and “Retry video”; clicking Retry leaves it unavailable. The image explains the missing host-file access. This is a fallback UI bug; no access bypass is reported.
[Bug]: A host video without file access shows "Video unavailable" and a Retry that cannot work#21087
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- Pair a client without the
filesystem:readscope, for examplet3 pair --scope orchestration:read --scope orchestration:operate, or use a desktop paired before that scope was a default. - Have an agent reply with a host video:
.
Expected behavior
The video says why it is unavailable, as a host image already does: "This connection cannot read host files. Pair again with a new link to view it."
Actual behavior
It shows "Video unavailable · Demo" and a "Retry video" button. The client blocks the asset before it asks the server, so Retry can never succeed, and nothing explains why.
Impact
Minor bug or occasional failure
Version or commit
main at 6a6ebb278. Seen on desktop 0.1.1-nightly.20261017.3272 against server 0.1.1-nightly.20261018.3285.
Environment
macOS desktop client connected over Tailscale to a Linux (WSL) server.
Workaround
Pair again with a link that includes filesystem:read.
Reproduced on b5a226e49c in the real web app paired without host-file access. Retry returned to the same unavailable state. #23223 shows the existing access explanation and removes that ineffective Retry. Focused browser tests pass 6/6; before/after evidence and unverified desktop/control paths are in the PR.