Browser panes cannot open public URLs or local urls when connected to Remote Server Instance with Kiro Desktop

[dixitrathod16]

Existing issues

• I searched open issues and this is not already reported.

KiroCrew version

0.5.0 desktop package (exact build stamp unknown)

Release channel

Insider

How is it installed?

Desktop app

Platform

Not platform-specific

What happened

In the Electron desktop app, submitting a public URL such as https://google.com/ in the Browser panel works for the local dashboard and opens the interactive native browser surface. The same URL submitted from an embedded remote-instance pane instead falls back to the preview iframe and reports Preview server not reachable.

Expected: an Electron-hosted remote pane should use the same interactive native Browser surface as Local Mode for public HTTP(S) URLs.

Steps to reproduce

1. Open the Kiro Crew Electron desktop app.
2. Connect a remote Kiro Crew instance and select its embedded pane.
3. Open a Browser panel in a remote session.
4. Submit https://google.com/ or another public HTTP(S) URL.
5. Observe Preview server not reachable instead of the live interactive page.
6. Switch to Local Mode and submit the same URL; it opens in Browser — live.

Relevant log output

The remote child frame has no window.browserAPI preload bridge. It attempts the ordinary preview iframe, which is intentionally blocked for arbitrary public origins by the gateway CSP.

Anything else

The remote dashboard is a cross-origin iframe inside InstancesViewport, so Electron preload APIs are unavailable in that child frame. Widening CSP is not the right fix.

A narrow, versioned parent/child lifecycle relay can preserve the trust boundary by requiring both the known warm tunnel origin and the exact iframe contentWindow, namespacing native panel IDs per instance, and allowing only the active pane to open or navigate. Agent commands, CDP, control ownership, and remote session tracking should remain on the remote gateway's Playwright transport.

Scope limitation: this gives public URLs Local/remote parity. Services bound to the remote VPS loopback still require an SSH port forward.

[github-actions]

Automated triage summary — generated from the issue text alone, before any maintainer has read it. Treat every line as a starting point, not a verdict.

In the Electron desktop app, submitting a public HTTP(S) URL in a Browser panel works for the local dashboard (opens the interactive native browser) but falls back to the preview iframe and reports "Preview server not reachable" when done from an embedded remote-instance pane. Reporter expects parity between local and remote panes for public URLs.

Worth adding

• the exact desktop build stamp for 0.5.0
• actual Electron/renderer console output or gateway logs from the failing attempt (the log field contains an explanation rather than logs)
• whether this ever worked in an earlier build or is new behavior

Possibly already reported

• Browser panel shows every session's browser, not the owning chat's #5940 (Browser panel shows every session's browser, not the owning chat's)

If one of these is the same problem, say so and we will close this as a duplicate.

_{Posted by issue-summary.yml. The model had no access to the repository — it read only this issue and the titles of recent ones.}

[dwu96]

🤖 Kiro Crew Auto-Pipeline [operator: dwu96#8c08bee0]: Routing to needs-human — the diagnosis holds, but the remedy is a trust-boundary architecture decision, not a mechanical fix.

Verified against main 9057fcf8:

• website/electron/main.js:1460 sets preload: preload.js on the window's webPreferences, and nothing sets nodeIntegrationInSubFrames. contextBridge.exposeInMainWorld("browserAPI", …) (website/electron/preload.js:149) therefore lands in the top frame only.
• bridge() in website/src/hooks/useNativeBrowser.ts:32-34 reads window.browserAPI and returns null inside the embedded pane, so native.available is false and the panel falls back to the preview iframe — the reported symptom.
• One wording correction: the pane iframe is same-site, cross-origin, not simply "cross-origin". InstancesViewport.srcFor deliberately serves it from the parent dashboard's own hostname on a different loopback port (see the comment at website/src/lib/tunnelOrigin.ts:14-17), so it is a distinct web origin while remaining same-site. That does not change the conclusion — a per-frame preload is still absent — but it matters to anyone designing the relay, since same-site is what makes the existing postMessage unread relay's origin allowlist workable.

Why this is not auto-fixable: the fix as described adds a new privileged IPC surface — a versioned parent/child lifecycle relay that lets a child frame open and navigate a real WebContentsView owned by the main process. Whether the desktop app should extend native-browser authority to an embedded remote instance at all is a security-posture call, and the safeguards named in the report (pinning to the warm tunnel origin and the exact contentWindow, per-instance panel-ID namespacing, active-pane-only gating) are the design, not a derivable consequence of the diagnosis. That is explicitly outside the automated bucket.

A maintainer should decide (a) whether remote panes get native-browser parity at all, and (b) if so, whether the authority flows through a parent-mediated relay as proposed or through the remote gateway's own Playwright transport, which already owns agent commands, CDP, and control ownership for that instance. No labels or assignees were taken.