BROWSER TESTING / 01

The agent changes the app. Then it can inspect what you see.

MidTerm docks the development browser beside the real PTY. You and the coding agent share one visible target, while explicit helpers expose structure, actions, logs, screenshots, and responsive state.

By · Updated July 14, 2026

CLOSED LOOP / 02

Build, inspect, act, verify.

The feedback loop stays in the workspace where the code, server, logs, and agent already run.

Open

Attach the real app

mt_open selects a URL, docks the Dev Browser, and waits for its bridge to become controllable. mt_status reports ready, waiting, or ambiguous instead of hiding attachment failure.

Inspect

Read bounded evidence

Start with mt_outline, then use mt_text, mt_query, mt_attrs, or mt_css for the exact part of the page that matters.

Act

Operate precise elements

mt_click, mt_fill, and mt_submit address explicit selectors. The agent can reproduce a flow without guessing coordinates from a screenshot.

Diagnose

Keep browser evidence attached

mt_log, mt_proxylog_summary, and mt_proxylog expose client errors and proxied requests; mt_screenshot preserves visual proof.

localhost:5173
A MidTerm terminal and its shared visible development browser shown side by side

MINIMAL LOOP / 03

The interface is executable documentation.

. .midterm/mtcli.sh

mt_open http://localhost:5173
mt_status
mt_outline
mt_query '[data-testid="save"]' --text
mt_fill '#title' 'Persistent browser test'
mt_submit 'form'
mt_log error
mt_screenshot

The generated helper is an authenticated client for the current MidTerm session. A PowerShell equivalent is generated beside it. Agents can discover the surface from inside the repo instead of depending on a remote model integration or an undocumented plugin.

Read the complete CLI and JSON control contract →

SHARED TARGET / 04

Visible to the operator. Addressable by the agent.

MidTerm's Dev Browser is deliberately not a hidden second world.

Human viewThe app stays beside the terminal. You can watch an action, take over, compare the layout, or inspect the same error the agent reports.
Agent viewCompact textual responses expose page structure and state without forcing the agent to consume a full screenshot for every check.
Host contextThe preview can reach the development server and private services available to that MidTerm host; its browser login state stays with the preview while code and server remain on the machine.
No inferred meaningMidTerm transports explicit browser state and commands. It does not decide whether the UI is correct; the agent and its instructions do that work.

RESPONSIVE + DEVICE / 05

Start with dimensions. Escalate to device signals.

A narrow screenshot proves only the narrow layout. MidTerm keeps responsive checks, Chrome device emulation, and real-device validation deliberately distinct.

Responsive frame

Set exact dimensions

mt_viewport 390 844 constrains the desktop iframe to a mobile-sized frame. Reset with mt_viewport 0 0. It does not change user agent, pointer, hover, touch, or lifecycle.

Structure

Check what moved

Query navigation, overlays, fixed controls, and the active form at the narrow width rather than assuming CSS breakpoints produced the intended layout.

Chrome device

Add device signals locally

The optional Mobile Device Bridge opens the preview in local Chrome with a Pixel profile, touch, Android identity, orientation, lifecycle, and keyboard-viewport approximation while retaining MidTerm's browser commands.

Real device

Validate the operating system

Use a physical phone for the actual software keyboard, Safari/WebKit, and OS-specific lifecycle behavior. A bridge screenshot cannot certify those boundaries.

BOUNDARY / 06

Use the right browser tool.

The shared visible target is the feature; it also defines the limits.

Choose MidTermFor iterative development where a terminal agent, developer, local server, and visible app should share one durable browser workspace.
Choose PlaywrightFor repeatable test suites, isolated browser contexts, multiple engines, CI execution, and high-volume automation. The tools can coexist.
Connected UI requiredBrowser commands need a live MidTerm browser tab and a controllable preview. If no UI client is connected, mt_open fails explicitly.
Device fidelityThe responsive frame changes dimensions only. The optional Chrome bridge adds Chromium device signals; Safari, iOS, and a real operating-system keyboard still require real hardware.
Security boundaryThe helper carries a machine-local session credential. Treat generated .midterm helpers as secrets and keep remote MidTerm access behind HTTPS, authentication, and preferably a private network.

ANSWERS / 07

Short answers.

Can a coding agent control MidTerm's Dev Browser?

Yes. Generated Bash and PowerShell helpers expose the selected preview's structure, text, attributes, computed CSS, actions, console and proxy logs, screenshots, and viewport size.

Is MidTerm a replacement for Playwright or a headless browser farm?

No. MidTerm optimizes for one shared, visible development browser beside a real terminal session. Playwright remains the better fit for repeatable suites, isolated browsers, and high-volume automation.

Does browser control require MidTerm's own AI?

No. The browser bridge and command helpers are deterministic control surfaces. The coding agent using them supplies the intelligence.

Can an agent test mobile behavior?

MidTerm's responsive frame is dimension-only. The optional Mobile Device Bridge adds Chrome device metrics, Android identity, touch, orientation, lifecycle, and a software-keyboard approximation. Real Safari, iOS, and operating-system keyboard behavior still require a real device.

Keep the app visible.
Give the agent exact controls.