Agents Don't Have to Fake Keyboard Input Anymore: wterm Turns Browser Terminals into Tools

Chris Tate posted an update on X: wterm now supports WebMCP. Terminals in the page can be used directly by agents, with capabilities including listing terminals, reading the screen and scrollback, waiting for output, typing commands, and sending keypresses. A key setting is enabled per terminal, and read-only mode is supported. In the demo, five fx agents launch one another across four browser terminals.

wterm is an experimental Vercel Labs project: a terminal emulator that runs in the browser. It renders with DOM, so text selection, copy and paste, browser find, and accessibility are implemented directly on the mounted lines. The core is written in Zig and compiled to WASM; the release build is about 26 KB. The project provides React, Vue, Svelte, and vanilla bindings, and the repo is at vercel-labs/wterm.

WebMCP can be understood as an interface layer through which a page exposes callable tools to agents. Previously, when agents operated a web terminal, the common approach was to scrape the DOM and then fake keyboard events. As soon as the UI changed, the scripts broke. Now the terminal exposes actions as tools; the agent calls the tools and doesn't have to guess the page structure. Ram Pathath said in a reply that when an agent types into the terminal without fake keypresses, it feels less brittle.

But the real thing to watch is the boundaries. John Rood said enabling per terminal and read-only are the right defaults. Many approaches just give the agent a full shell and then bet that prompts can constrain it; the blast radius is whatever happens to be in the working directory. That's a bit harsh, but it hits on the problem.

Read-only is not zero-risk either. Zhao Liu pointed out that terminal output may contain tokens, customer data, and logs. Max Petrusenko added that read-only blocks input, but whatever the terminal prints still enters the context of the agent reading it. Permissions, visibility scope, and redaction have to be considered together.

There are several unanswered questions in the comments. Moriarty asked whether reading returns the full scrollback or only the current screen, which determines whether an agent can follow a long build log to the end. Asmir asked whether it gets the fully retained output or a snapshot from readText(). Ignacio Ferro Picón asked whether wait-for-output uses OSC 133 prompt state or a silence timeout. In a raw terminal, a command finishing and a command being slow look the same; only with OSC 133 is there a chance to get the exit code. Brent Summers asked whether one agent can read another terminal's output, or only the terminals that have been opened. These questions matter more than the demo, because they determine whether the tool is usable in real workflows.

The placement of WebMCP is also interesting. Yiyang Suen asked: in many cases the CLI is more direct than operating a UI, and agents can already open a terminal, so why go through WebMCP? soren law's answer was that for in-page terminals, WebMCP is the right layer; agents that fake DOM keypresses break every time the UI adjusts, and opt-in plus read-only lets an agent watch logs first without giving it write access.

This demo isn't big, but it has plenty of signal. The terminal goes from a window people look at to an interface agents can call. How that interface is opened, who it's opened to, and how much it grants are the parts to watch next. wterm sets the defaults to per-terminal enablement and read-only, which is the right direction. What remains is how the implementation answers questions about read scope and output leakage.