HTML Apps have no way to open external links in the browser

[marcodlk]

What problem are you trying to solve?

HTML Apps run in a sandboxed iframe (sandbox="allow-scripts allow-forms", no allow-popups, no allow-top-navigation). That's the right default, but it means an app has no way at all to send the user to an external website: plain <a href="https://..."> clicks navigate nowhere useful inside the frame, target="_blank" and window.open() are blocked by the sandbox, and the window.hubble runtime only exposes files.* methods.

Concrete example: a "reading list" HTML App that lists bookmarks from Markdown front matter can render the URLs but can't open any of them in the browser.

The Markdown editor already solves this for note links: clicks go through desktopApi.openExternalUrl(href) → desktop:open-external-url IPC → shell.openExternal(url), with the main process rejecting anything that isn't http(s).

Proposed solution

Extend the runtime broker (per ADR-0007, "future APIs should extend the runtime broker") with a links.open method:

• window.hubble.links.open(url) / window.hubble.links.safeOpen(url) on the injected runtime global, matching the files.* style.
• The renderer-side hubble:request handler validates the URL (http/https only, same rule as the existing main-process guard) and forwards to the existing desktopApi.openExternalUrl. No new IPC surface.

I have a small draft PR ready to pair with this issue — happy to adjust the naming or approach based on discussion here.

[github-actions]

Triage: needs discussion — the gap is real and verified, but adding a non-file broker namespace involves product and security decisions worth settling before implementation.

What the code confirms today:

• HTML Apps really have no escape hatch: the iframe is sandbox="allow-scripts allow-forms" (apps/desktop/src/editor/IframeView.tsx:173), the same sandbox is re-applied as a CSP header on hubble-asset:// HTML responses (apps/desktop/electron/main.ts:765), will-frame-navigate blocks any subframe navigation that isn't hubble-asset:///chrome-extension:///about:blank (apps/desktop/electron/main.ts:1205), and setWindowOpenHandler denies all popups (apps/desktop/electron/main.ts:1221).
• The runtime global exposes only files.* (packages/runtime/global.js:46), and the broker only handles files.* methods (IframeView.tsx:223).
• The proposed reuse target exists and is already scheme-gated to http(s) in main (apps/desktop/electron/main.ts:1770), reached via desktopApi.openExternalUrl.

Why this isn't ready-to-implement yet:

• Scope beyond the ADR. ADR-0007 says future file APIs should extend the broker, and CONTEXT.md only defines an "HTML App File API" (CONTEXT.md:73). links.* is a new capability class, so ADR-0007 and the glossary need a deliberate update, and the namespace/method naming (links.open vs shell.* vs app.openUrl) is a maintainer call.
• Exfiltration/consent. HTML Apps are often agent-authored and can already read workspace Markdown via files.read. An unconstrained links.open(url) lets an app silently ship note contents to an arbitrary host in query/fragment params with no user gesture. files.remove set the precedent that risky operations prompt (IframeView.tsx:459), so whether external opens need a user gesture, a confirmation showing the URL, or no gate at all is an open product decision.
• Two valid designs. An imperative links.open(url) is one option; intercepting plain <a href="https://…"> clicks inside the runtime and brokering them is another, and arguably better DX since existing apps and agent-generated markup would just work. These aren't mutually exclusive, but the default should be chosen up front.

Not a duplicate of #228 — that one is about mod+click behavior for links in the Markdown editor, a different surface with a working open path.

Questions to settle:

• Should this be an imperative window.hubble.links.open(url), automatic brokering of <a target="_blank">/plain anchor clicks, or both?
• Does opening an external URL require user consent (confirm dialog showing the host), a trusted user-gesture check, or nothing beyond the existing http(s) guard? Does the exfiltration risk from combining files.read + arbitrary URLs change that answer?
• Final naming and shape: links.open/links.safeOpen matching the files.* throw + safe* convention, or a different namespace?
• Which docs land with it: an ADR-0007 amendment plus a new CONTEXT.md glossary entry generalizing the broker beyond files?
• Should non-http(s) URLs throw with a specific message, and should this record telemetry the way usedHtmlApp does?

---

Triaged by a Warp Factory agent.

---

Triaged by a Warp Factory agent.

[marcodlk]

for transparency, this issue was fully clanker written, created by accident.

created a personal fork so i could open links directly from html apps in Hubble. is this something of interest to maintainers? if so, could create a PR with more thought.