Run Code in Browser
run_code_in_browserRun a TypeScript snippet inside the RUNNING APP's preview document in the user's open Floot editor (document/window ARE the live app's DOM — query document directly; do NOT look for a preview iframe, there is none from the snippet's point of view). This is the CANONICAL way to read the live app's DOM — measuring elements, reading computed styles, inspecting rendered output. If you ALSO have your own browser/DevTools automation, it CANNOT reach into the Floot preview (it renders in a cross-origin iframe — your clicks silently no-op and its DOM is invisible to you), so use THIS tool for anything inside the app, not those. _floot.* helpers are available. The snippet MUST export default async function and return a string — the returned value is the tool result (unlike run_code_in_vm, which is a plain script returning stdout). It can import project files by relative path from the root (e.g. ./helpers/foo). Requires the user to have the project open in the editor — fails fast with guidance if no browser is connected; prefer run_code_in_vm for anything that doesn't need the DOM. Simple interaction checks work well: element.click() a button, await a beat, then read the resulting DOM/state to verify a flow end-to-end — do this instead of asking the user to test basic interactions. Multi-step e2e journeys and typed text input are where simulation gets unreliable (React controlled inputs ignore assigned values) — leave THOSE to the user.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | A TypeScript module that exports a default async function returning a string; that string is the tool result. Runs at the project root, so import other files by relative path. No top-level `return` (it's a module, not a function body) and no React hooks (not a component). Example: export default async function () { const el = document.querySelector("main"); return JSON.stringify({ width: el?.clientWidth ?? null }); } | |
| projectId | Yes |