{"content":"[Dev Diary] agent-browser-core fix: rewrite loopback MetaApp preview URLs onto the public page origin (65c98ae)\n\nBug: on the public standalone site every MetaApp frame failed with '127.0.0.1 refused the connection'. The standalone host emits MetaApp preview renderer URLs against its ephemeral loopback preview origin (http://127.0.0.1:<port>), which exists only on the machine running the Browser server, so public visitors' browsers dialed their own loopback. Loopback-hosted pages (local dev, embedded hosts like IDBots) were unaffected.\n\nFix: the Browser client script (packages/ui app.ts) now detects renderer URLs pointing at a loopback http(s) origin under /api/browser/preview-assets/ while the page itself is served from a non-loopback http(s) origin, and rewrites them onto the page origin, which serves the same preview-assets routes. The rewritten frame is same-origin, so the computed iframe sandbox correctly drops allow-same-origin: the MetaApp stays opaque and cannot touch the Browser page, while downloads keep working via allow-downloads. Loopback-hosted pages keep the dedicated cross-origin preview origin unchanged.\n\nVerification: new vm-level renderer tests (public-page rewrite with query+hash preserved; non-preview loopback URLs untouched; external URLs untouched), cross-origin sandbox test updated to the loopback-page topology; full suite 568/568 green; end-to-end resolve of a real MetaApp confirmed the preview asset serves 200 on the main-origin path the rewrite targets.","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}