When vibe coded apps break, mk0r has 800 milliseconds to catch it

The three failure shapes

Almost every break in a vibe-coded session collapses into one of three shapes. None of them are exotic. Naming them is the first step, because the catch in mk0r is a different mechanism for each.

1. Loud break. A runtime error throws inside the iframe. Vite's overlay appears and Vite emits vite:error. This is the easiest shape to catch. The bridge posts hmr:error to the parent and the rolling buffer keeps the message for the next turn.
2. Silent break. The bundler is happy, the page renders, but a new component is not actually on screen because nothing imports it from App.tsx. No error fires. The page just stays the same or goes blank. This is the shape the global CLAUDE.md addresses with one specific instruction.
3. Stuck break. HMR never settles. Maybe the bundler is mid-rebuild, maybe a websocket reconnect is in flight, maybe the dev server is paused. The 800 millisecond timeout is the safety net for this shape: the iframe hard-reloads with a new nonce and the user sees the current bundle, broken or not.

What the parent page actually logs during a real break

Open the parent devtools while the iframe is running and you can watch this happen on a live session. Every line below is a real shape emitted by code in src/components/phone-preview.tsx and src/core/vm-scripts.ts. The error type is illustrative, the bridge does not invent the message, it forwards whatever Vite hands it.

The full catch-and-fix cycle, one turn end to end

The pieces above only matter if they wire together inside one loop. They do. Here is the actual sequence between a prompt and the next ready-to-prompt state, with file paths so anyone can open the source and verify it.

The blank-page rule

The single most important sentence for catching the silent failure mode lives in src/core/vm-claude-md.ts at line 282. The whole sentence is: If the page is blank, verify the component is imported in App.tsx. That sentence is installed into the sandbox at /root/.claude/CLAUDE.md before the agent ever boots, so it is part of the agent's working memory on every turn.

Why dedicate a rule to one symptom? Because the silent failure is the most expensive one to debug without a rule. The bundler has no error to report. The HMR client has no error to forward. The browser has nothing to put in the console. By default the agent would scan the diff, fail to find a bug, and burn a whole turn. The rule shortcuts the search: the answer is almost always that a new component file was created and never rendered from App.tsx. One edit, one HMR cycle, the page is back.

You can read the surrounding workflow at lines 273 to 283 of the same file. It is a four-step browser-testing checklist: navigate to localhost:5173, take a Playwright snapshot, check browser_console_messages, and refuse to report completion until the page actually renders the expected screen.

The undo path, for the cases where the catch missed

No catch loop is perfect. Some breaks only show up on a code path the agent did not exercise during verification. A button works on the first click and crashes on the second, a form renders but a submit handler throws on a value the agent did not type. Those breaks ship. The recovery for them is not inside the 800 millisecond window, it is downstream of it.

On every turn that produced a diff, commitTurn in src/core/e2b.ts runs git add -A followed by git commit -q at line 1649 against the project repo inside /app. The resulting SHA is recorded on the session record. Undo is therefore not a snapshot heuristic and not a diff replay, it is git checkout against a known commit. The bytes you get back are the bytes that were in the tree at the end of the previous turn, exactly.

That is true even after the sandbox has paused (E2B's one hour idle pause, see the iteration-wall guide below), been reaped from the warm pool, or you closed the tab and came back. The next prompt restores from the head SHA in Firestore before the agent runs anything new.

What this does not catch

The honest framing: the catch loop is for a class of breakage, not all breakage. There are three kinds of failure the 800 millisecond window does nothing about, on purpose.

• Logic that looks right and is wrong. A correctly-rendering calculator that adds wrong. An animation that plays at the right time but with the wrong easing. The catch loop only sees what HMR and the browser console can see. Wrong-but- running output requires the user to notice.
• Backend behavior the prototype does not actually have. The sandbox runs a Vite + React frontend. There is no real authentication tier, no production database load, no third- party rate limit to hit. Failures that only appear under those conditions cannot break a vibe-coded session because those conditions are not present.
• Things that broke in a previous session. The console buffer is scoped to the current iframe load. A nasty error from a session two days ago is not still sitting somewhere waiting to be read. That makes the catch loop fast, but it also means a regression introduced and reverted before the current session has no echo.

Why this matters more than the model itself

The dominant story about vibe coding is that it succeeds or fails based on how good the underlying model is. That is part of the truth and not the load-bearing part. Every model fails some percentage of the time. What changes the felt quality of a session is whether the failure is caught inside the same turn or whether it surfaces three prompts later with the user confused about what they did wrong.

The 800 millisecond catch window is small. The console buffer is a few hundred lines. The blank-page rule is one sentence in a configuration file. Each piece on its own is unimpressive. Together they make the difference between a tool that vibe-codes and a tool that vibe-codes and notices.