A code generator app for X, where X is whatever you type, and you watch it build.

What every guide on this topic misses

Open the other pages that currently rank for this topic. They all do the same thing. They list the Xs the tool can produce. Forms. Tables. Landing pages. Signature blocks. Pricing grids. The list is almost identical across every tool because the underlying models overlap in training data. What none of those pages explain is the mechanism between prompt and pixel. They show a before and an after, never the middle.

The middle is where differentiation lives. If your generator ships the finished zip, the middle is a black box. If your generator shows the preview as a static iframe refresh, the middle is a stall. If your generator is wired into a real Vite dev server and forwards the HMR lifecycle to your browser, the middle is a live signal you can read. mk0r picks the third option, and the piece that makes it work is a 28-line file you can grep for in the public repo.

The bridge, in full

Below is the entire contents of docker/e2b/files/app/src/_mk0rBridge.ts. It is copied into every sandbox at /app/src/_mk0rBridge.ts, and the entry file src/main.tsx imports it before anything else mounts.

Three things to notice. First, every message carries a source: 'mk0r-preview' tag. The parent window uses that tag to filter out unrelated cross-origin noise, because a real browser iframe receives postMessages from every script that runs inside it. Second, each payload includes ts, the millisecond timestamp, which lets the parent measure time between events and surface it. Third, the HMR events carry an updatescount. That count is the number of modules in the current hot update, which is how the UI shows "3 modules updated" instead of "something changed."

How the event flow actually moves

The agent writes a file. Vite's file watcher fires. Vite emits vite:beforeUpdate. The bridge catches it and posts hmr:before to the parent. Vite compiles. Vite emits vite:afterUpdate. The bridge posts hmr:after. If anything broke along the way, Vite emits vite:error and the bridge posts hmr:error with the message text.

The bridge is intentionally thin. It does not transform payloads, rewrite messages, or batch events. Vite already emits the right shape. The bridge just forwards. That thinness is what makes the preview feel fast. There is no intermediate layer deciding when to refresh a screenshot.

Where the bridge sits on boot

The sandbox startup script boots Vite on port 5173 before anything else that listens on an external port. Once Vite is up, the bridge loads on the first page hit because src/main.tsx imports it at the top.

The "wait until port 5173 accepts a TCP connection" loop is what lets the rest of the pipeline trust that the preview iframe will have something to render. Without it, the first prompt could race the dev server and the user would see a 502 from the proxy on port 3000.

The rule that protects the bridge

The agent runs inside the sandbox and has write access to the whole filesystem. Without a clear rule, it would occasionally decide to "clean up" the bridge file because it does not look like application code. The project's CLAUDE.md pins the bridge as untouchable.

The wording matters. Saying "do not modify" without saying why will sometimes lose to an agent that decides the rule is obsolete. Anchoring the rule to a concrete import in src/main.tsxgives the agent a reason that survives "but I refactored main.tsx" reasoning. The bridge import must stay because the parent window needs the messages, and the agent cannot see the parent window from inside the sandbox.

What the console shows when the bridge is doing its job

Here is an abbreviated trace from a real sandbox session where the agent built a habit tracker. The command output and bridge console logs interleave because both stream to the preview window.

One generator, many Xs

Because the scaffold is identical every time, X can be anything the agent can express as React components that fit inside a Vite project. The bridge is agnostic to what the components do. It forwards the same five events whether X is a signature pad or an internal dashboard.

The sequence from prompt to rebuild, end to end

If you read the bridge without the surrounding flow, it looks like a postMessage utility. It only earns its place when you trace the chain from prompt submit to the preview redrawing.

Versus the generator pattern most tools still use

A lot of code-generator-for-X tools still treat generation as a one-shot: prompt goes in, a finished artifact comes out, the user decides whether to keep or regenerate. mk0r swaps that for a continuous loop that reports itself.

The part worth copying

If you are building a code generator app and you want the preview to feel alive, the lesson is not the 28 lines. The lesson is that the dev server already emits the events you need, and the only novel work is forwarding them over a channel the host frame can read. Vite gives you vite:beforeUpdate, vite:afterUpdate, vite:error, and vite:beforeFullReload for free. The bridge just adds a 0 -line translation to window.postMessage. Steal it.