Datasette Apps 0.2a0: the agent smoke-tests its own UI in an invisible iframe

Simon Willison shipped datasette-apps 0.2a0, a small alpha release aimed exactly where agent-built UI usually fails: feedback after the app is generated.

The agent gets app_debug() and can probe an app without user clicks

The new app_debug() tool opens a Datasette App in an iframe with opacity: 0 and pointer-events: none. The user neither sees it nor interacts with it. The agent injects its own JavaScript into that sandboxed iframe, measures elements, checks that the UI rendered at all, and runs a smoke test.

Alongside it comes app_list(): the agent can list apps the user is allowed to edit, instead of guessing slugs or reaching outside permissions. Both changes target the workflow where Datasette Agent creates and edits apps, not merely describes them.

Under the hood this uses context.browser_task() from datasette-agent 0.4a0. That plugin lets the agent run JavaScript directly in the user's browser. Datasette Apps is the first concrete consumer of the loop.

For small internal apps, who catches the broken render is changing

Datasette Apps hosts custom HTML and JavaScript applications inside a Datasette instance, often on top of SQLite data. The typical use case is a quick internal utility: a filter, a dashboard, a small form. When an agent writes it, the painful part is rarely SQL. It is a silent fail in the DOM, CSS, or permissions.

app_debug() shortens the distance between "generated" and "checked". The agent does not have to wait for a human to click and type "scroll is broken". It can measure layout and catch trivial regressions immediately. app_list() keeps the edit loop inside Datasette's permissions model, which matters more than a flashy demo on multi-user installs.

For people who treat Datasette as a thin application runtime over data, the signal is clear: the agent is moving from SQL autocomplete toward a tighter build-test cycle inside the same product.

An alpha release still depends on trust boundaries and one browser

This is 0.2a0. APIs and behavior can still move, and Willison is not pitching an enterprise computer-use platform. A smoke test in an invisible iframe catches coarse failure better than subtle UX regressions, flaky async states, or data-level security holes.

Running agent-supplied JavaScript in the user's browser is powerful and sensitive. It only makes sense with a hard permissions model, audited tool calls, and explicit user consent. Without that, a convenient debug loop becomes a side channel into more session context than you expect.

Durability will show if the debug loop survives beyond demo apps

Watch whether browser_task spreads into other Datasette plugins, not only Apps. Second, whether app_debug() grows realistic assertions (auth states, write paths, empty states) or stays at measuring div width. Third, operations: do permission boundaries hold when the agent edits several apps in a shared instance.

If the loop holds, Datasette offers a practical pattern for small agent-built tools: generate, test invisibly, only then show a human. If not, it remains an elegant alpha detail for fans of the plugin ecosystem.

Lilith's verdict

Willison gave the agent a one-way mirror: it can poke the app with JavaScript in an invisible iframe before showing it to you. That is the moment an HTML generator starts looking like a real build-test loop.