AI app prototype limits: four iframe permissions, not the model

Because the preview iframe is what decides whether your AI-built prototype actually behaves like a real app at runtime. Context windows and rate limits cap how much the model writes; the iframe sandbox caps what the running app is allowed to do once that code is on the page. mk0r mounts the live preview with exactly four sandbox permissions — allow-scripts, allow-forms, allow-popups, allow-same-origin — defined on lines 155 and 163 of src/components/phone-preview.tsx. Anything outside that four-token whitelist is silently denied. A Stripe checkout redirect that tries top-level navigation will not redirect. A Web Share API call will not pop the share sheet. A Fullscreen API request will not enter fullscreen. None of these are model failures and none of them show up as errors in the chat; they are runtime limits encoded in one HTML attribute that no other guide on this topic mentions.

allow-scripts lets the iframe run JavaScript at all (without it, your generated React app does not boot). allow-forms lets <form> submissions go through the browser's form handler instead of being silently dropped. allow-popups lets window.open() succeed, so a prototype with an OAuth or 'Sign in with Google' button can pop the consent screen in a new window instead of getting null back. allow-same-origin keeps the iframe in the parent's effective origin so cookies, IndexedDB, localStorage, and the Vite HMR WebSocket all work; without it the app would boot in a unique opaque origin where every storage API throws a SecurityError. Together those four are the smallest set that lets a real React + Vite app, with cookies and OAuth popups, run without modification.

Everything not in the four-token list. The HTML5 sandbox attribute is a deny-by-default whitelist, so any token mk0r does not include is blocked. That means: no allow-top-navigation, so window.location='/checkout' or a meta refresh does not navigate the parent tab. No allow-modals, so window.alert(), window.confirm(), and window.prompt() are no-ops that return immediately. No allow-pointer-lock, so a built-in browser game cannot capture the mouse. No allow-orientation-lock, no allow-presentation, no allow-storage-access-by-user-activation. No allow-downloads, so a prototype that triggers a file download with a hidden anchor click will be blocked from initiating the download. If your generated app needs any of these, the limit is the iframe attribute, not the model.

HMR_WAIT_MS is the time mk0r gives Vite's hot module reload bridge to repaint after the agent writes a file, before falling back to a full iframe reload. It is set to 800 ms on line 24 of src/components/phone-preview.tsx. The mechanism: when the agent finishes writing a file, the parent bumps a refreshNonce prop. The preview component arms a timer for HMR_WAIT_MS, listens for an hmr:after postMessage from the in-iframe Vite bridge, and either skips the hard reload (if the message arrives) or cache-busts the iframe URL with a ?_=<nonce> query parameter (if the timer fires first). Eight hundred milliseconds is the budget because most React component edits paint in 100 to 400 ms and most CSS changes paint in under 200 ms, so 800 ms tolerates a slow hot reload while still falling back fast enough that the user does not notice an extra step. There is no way to retry HMR without reloading; the timer fires once.

DEVICE_SIZE.mobile = { w: 390, h: 844 } on line 9 of src/components/phone-preview.tsx. Those are the CSS pixel dimensions of an iPhone 14 Pro in portrait, which mk0r treats as the canonical mobile preview size. The iframe is rendered at exactly those pixel dimensions in mobile mode; the user's generated app then runs at that resolution and any responsive breakpoints below 768 px will activate. Desktop mode sets DEVICE_SIZE.desktop = null, which switches the iframe to width:100% height:100% — the prototype fills the available preview pane. There is no third 'tablet' mode, which means a prototype that targets the 600 to 1024 px range is shown either at 390 px wide or at the full pane width, never in between. This is the only mobile cap and it is hardcoded; no media query inspector chooses other sizes.

Two iframes overlap. When refreshNonce changes and the HMR timer fires without an hmr:after message, the live iframe's nonce becomes the new refreshNonce, but the OLD nonce is kept on a second iframe (prevNonce) layered absolutely behind it. The live iframe loads the new src; while it is loading, the previous iframe is still painted underneath, so the user does not see a blank flash. As soon as the new iframe fires onLoad (line 165), prevNonce is cleared and the previous iframe unmounts. The whole double-iframe trick is in src/components/phone-preview.tsx around lines 150 to 168. Visible in network: the same dev server URL is requested twice with different ?_=<nonce> values for ~50 to 300 ms. This is what makes a hard refresh feel seamless even though it is not actually HMR.

Vite's HMR uses a WebSocket from the iframe back to the dev server. Without allow-same-origin, the iframe runs in a unique opaque origin and the WebSocket either cannot open at all or is treated as cross-origin against the dev server's CORS policy, so HMR breaks immediately. mk0r's dev server lives on port 5173 inside the E2B sandbox (VITE_PORT = 5173 on line 785 of src/core/vm-scripts.ts) and is reverse-proxied to the user's preview URL. Keeping the iframe in the parent origin means cookies set by the prototype are scoped to a real domain, localStorage persists across reloads, and the in-iframe postMessage handler can address window.parent without a window.parent.postMessage origin check failing. Drop allow-same-origin and almost every modern web framework breaks; mk0r keeps it because the alternative is unusable.

Not from the prompt. The sandbox attribute is rendered by the parent component (src/components/phone-preview.tsx) and is not exposed as a prop or a setting. The agent cannot edit it because the file is outside the prototype's project directory inside the sandbox; it lives in the mk0r app shell, not in the generated app. If your prototype needs a permission outside the four-token list, the working pattern is: detect that you are running inside mk0r's preview by checking window.parent !== window, branch the UI, and in the deployed (non-iframe) build, run the full feature. The published version of your app, served from your own custom domain after billing entitlement, runs without any sandbox at all because it is no longer inside an iframe.

Open DevTools on the parent page and look at the iframe in the Elements panel. If a feature is silently broken (no chat error, no streaming red banner, the agent insists the code is right), check the console of the iframe itself; sandbox-blocked actions log a message like 'Blocked navigation to ... a frame because it is sandboxed and the allow-top-navigation flag is not set.' That message is the giveaway. The agent has no visibility into runtime browser security errors, so it will not catch them or self-correct. The fix is almost always to redesign the feature for the four allowed permissions or to defer it to the published deploy where the sandbox is gone.

Yes. mk0r's failure surface for one prompt turn is documented in our companion guide on the eleven terminal states (six error kinds plus five model stop reasons). The seven runtime clocks that govern timing — request timeout, TTFT watchdog, sandbox TTL, pool age, tab pause, and two attachment caps — are documented in the one-shot prototype limits guide. This page is specifically about the preview layer, the part of the stack that decides what your generated app is allowed to do once the code is on the page. Three layers, three guides, all checkable in the repo.