feat(harness): add local preview capability preflight #5234

Activity

1. liugddx commented on Sep 12, 2026

   

   liugddx

   on Sep 12, 2026

   MemberAuthor

   More actions

   Observed browser/tool errors: navigating a local URL returned . The session also attempted a shell-started localhost server, but the later curl check was connection refused. These are observations from one environment; the issue must test and classify supported, unsupported, and unknown capability states instead of assuming a single sandbox cause.
2. liugddx commented on Sep 12, 2026

   

   liugddx

   on Sep 12, 2026

   MemberAuthor

   More actions

   Observed browser error: navigating a local file URL returned Desktop Browser admission requires an HTTP origin. The shell localhost workaround also failed a later connection check. These are observations from one environment; capability classification must distinguish supported, unsupported, and unknown rather than assume one sandbox cause.
3. ying-hua commented on Sep 13, 2026

   

   ying-hua

   on Sep 13, 2026

   Contributor

   More actions

   take
4. github-actions

   assigned

   ying-hua

   on Sep 13, 2026
5. Astro-Han

   added

   enhancementNew feature or requestNew feature or request

   on Sep 17, 2026
6. Astro-Han commented on Sep 17, 2026

   

   Astro-Han

   on Sep 17, 2026

   Contributor

   More actions

   The observations behind this issue came from a session where local file:// navigation was rejected and a shell-started localhost server was unreachable. Since then #5213 and #5238 have both closed as completed, and managed HTML artifact previews are served over a loopback HTTP endpoint (#5316, 512605fd10f1cef0a9f65c1605c15eb5e2cf31fb). Could you re-measure on current main and say which capability states are still unverifiable through that endpoint? Without that, a separate preflight path risks duplicating discovery for a case that is already covered.
7. ying-hua commented on Sep 18, 2026

   

   ying-hua

   on Sep 18, 2026

   Contributor

   More actions

   Thank you — this was the right thing to ask, and re-measuring changed what this issue should say about itself rather than just confirming it.

   I re-measured on current main (5b9db1ce8), reading ManagedArtifactPreview.prepare as it now stands.

   What the managed endpoint does cover. It is stronger than a listening socket: after binding, it issues a HEAD against the exact authorized route and only returns reachable: true on a 200 whose content-length matches the bytes it holds. For the endpoint it just created, that is genuine reachability evidence, and #5235 correctly owns the loaded half.

   What stays unverifiable through it. The overlap with this issue is one axis — "is there a loopback endpoint that answers" — and only for its own endpoint. It cannot report:

   • GUI availability. prepare never consults the browser view host. In a runtime with no GUI at all it still succeeds and hands back a URL nothing can display. This is the sharpest case: its success is not evidence that a preview can be shown.
   • View reachability. Whether this conversation's embedded view will accept an action right now is a visible-lease question nothing in that path asks.
   • URL-scheme policy. Why file:// fails, and that the failure is a deliberate boundary rather than a defect, is still discovered only by attempting it.
   • Filesystem visibility. The managed path serves HTML from memory, but Save As and Show in Folder still materialize into the staging root, and nothing reports whether that round-trips.
   • Any caller-supplied endpoint. A server the caller started themselves is outside its scope entirely — and that is precisely where the refused-connection inference in fix(desktop): make generated HTML previews truthful and directly openable #5213 was made.
   • Three-state classification at all. prepare reports failure by throwing; there is no unknown, and Preview endpoint health check failed does not distinguish a slow start from a wrong route from an isolated namespace. That distinction is the whole point of this issue, and it cannot be recovered from an exception.

   So the preflight is not duplicate discovery: it answers before an artifact exists and before anything is attempted, which is when the caller is deciding what to try, whereas the managed endpoint answers about one already-created endpoint and only in success-or-throw form.

   The open PR (#5254) now reflects this. surface — can this client display a page at all — is reported separately from endpoint, which is not_checked rather than negative when no origin was supplied, and the ArtifactPreview handoff is what an unready report points at, carrying that tool's own caveat that reachable is a Desktop-side check and not a browser load. The PR body documents this relationship directly.

   If you still read the remaining axes as better served by extending the managed endpoint than by a separate preflight, I would rather settle that now than after review.
8. liugddx

   closed this as completedin #5254on Oct 10, 2026