Terminator: a Windows-only computer-use MCP agent for Claude, Cursor and VS Code

What Terminator is for, and who it is actually for

The README describes Terminator as a "Computer Use MCP that controls your entire desktop" and gives AI assistants such as Claude, Cursor and VS Code the ability to drive applications. The target reader is an engineer who already has an MCP-capable client and wants that client to click, type and read UI elements on a Windows machine, rather than a team looking for a cross-platform RPA suite.

The stated use cases are narrow and concrete: creating a GCP instance and connecting to it over a CLI, checking Vercel logs for the most common errors, and testing new app features based on recent commits. Those are developer chores, not back-office data entry. The project also markets a workflow builder and managed hosting for teams that want to record processes and deploy them without managing Windows VMs, but that product lives at mediar.ai and is separate from the repository you would fork.

The licence is MIT, and the README repeats that framing: "fork it, ship it, no lock-in." For an agent that runs on your own desktop with your own cookies, that matters more than it would for a hosted API, because the code has to run somewhere you control.

How the MCP agent, the Rust core and the browser extension fit together

The repository is a Cargo workspace, and that layout tells you most of the architecture. Members include crates/terminator (published as terminator-rs), crates/terminator-cli, crates/terminator-computer-use, crates/terminator-mcp-agent, crates/terminator-workflow-recorder, and two bindings under packages/: terminator-python and terminator-nodejs. The workspace pins a shared version, 0.24.32, and shares dependencies rather than duplicating them.

On Windows the element layer is built on the uiautomation crate, with the windows crate and sysinfo alongside it. That is the mechanism behind the locator table in the README: finding elements by name, role or window is UI Automation work, not screenshot guessing. Screen and element capture use xcap and image, and uni-ocr is listed among the vision dependencies, so pixel-level reading exists as a fallback path next to the accessibility tree.

The README claims three dimensions, "pixels, DOM, and Accessibility tree", and that combination is the interesting design decision. DOM access comes from a Chrome extension, which the support table lists under Browser Automation. Workflow recording is a separate crate, terminator-workflow-recorder, and the release notes describe OS event recording that generates YAML in the MCP agent. The intended flow is that a recorded human workflow becomes deterministic code, and the model is called only for recovery. That is a different bet from agents that re-plan every step through a model.

Installing Terminator MCP in Claude Code, Cursor or VS Code

The quickest path is the Claude Code one-liner from the README. It registers an MCP server named terminator that runs the npm package through npx.

claude mcp add terminator "npx -y terminator-mcp-agent@latest"

For other clients, the README gives an MCP config block. The server entry is named terminator-mcp-agent, the command is npx, and the args pin the same package. Two environment variables appear in the example: LOG_LEVEL set to info and RUST_BACKTRACE set to 1.

{
  "mcpServers": {
    "terminator-mcp-agent": {
      "command": "npx",
      "args": ["-y", "terminator-mcp-agent@latest"],
      "env": {
        "LOG_LEVEL": "info",
        "RUST_BACKTRACE": "1"
      }
    }
  }
}

After saving that config and restarting the client, the client should list terminator-mcp-agent among its MCP servers and expose its tools. The README points to the MCP Agent README for detailed setup, and the repository also ships a .devcontainer directory, so a container-based setup is at least anticipated by the layout even though the README does not walk through it.

If you want the library rather than the agent, the README names two packages: terminator-rs on crates.io and @mediar-ai/terminator on npm. The Python binding is listed as pip install terminator and marked Partial in the support table, which is a caveat worth reading before you build on it.

The Windows-only boundary is the first thing to check

The README is blunt: "Terminator currently supports Windows only. macOS and Linux are not supported." Every row in the feature table, from element locators to monitor management, is Yes for Windows and No for both other platforms. The only cross-platform-looking entry is the macOS button at the top of the README, which links to app.mediar.ai rather than to this repository.

That single constraint rules out a large class of deployments. If your CI runners are Linux containers, Terminator is not the tool. If your product is a macOS app, it is not the tool. The examples directory contains files such as macos_calculator.py and gnome-calculator.py, and those names are easy to misread as platform support; the support table is the authority, and it says No.

The second boundary is the Python binding. The table marks Python as Partial while TypeScript is Yes. A team that standardises on Python for automation glue should treat the Python route as unproven from the documentation alone and check the binding's own README before designing around it.

A third caveat is that the README does not document rollback, dry runs, or how to undo a half-completed workflow. For an agent that types into live applications, that silence is worth noting.

What Terminator does differently from Playwright and browser-only agents

The project describes itself as "playwright for windows computer use", and the comparison that matters is with Playwright itself. Playwright drives browsers through their automation protocols. Terminator drives the desktop, and its browser story is a Chrome extension rather than a protocol client, which is why the README can promise that it "uses your browser session" with existing cookies and auth. If your task is entirely inside a web page, Playwright is the more direct tool and does not need a Windows host.

The sharper difference is against model-per-step computer-use agents. The README claims Terminator "runs 100x faster" than ChatGPT Agents, Claude, Perplexity Comet, BrowserBase and BrowserUse, and attributes that to pre-training workflows as deterministic code with AI called only for recovery. Treat that number as a vendor claim, not a measurement you can verify from the repository. The architectural claim underneath it is checkable: a separate workflow-recorder crate exists, and the release notes describe OS event recording that produces YAML.

That design has a cost. Deterministic workflows need recording and maintenance, and they break when an application changes its UI. A pure vision agent degrades more gracefully but pays per step. Terminator's bet is that most desktop chores repeat, so the recording investment amortises. Whether that holds depends on how stable your target applications are.

Maintenance, releases and what the MIT licence leaves you

The last push to the default branch was on 2026-06-02. The most recent tagged release is v0.24.32 from 2026-04-05, preceded by v0.24.31 on 2026-04-02 and v0.24.30 on 2026-03-17. The repository is not archived. Releases are frequent enough that pinning a version is sensible: the install snippets use terminator-mcp-agent@latest, which means an unattended setup can change under you between runs. Pinning a specific version in the args array is the obvious mitigation, and it is a change you make in your own config, not something the README prescribes.

Upgrade cost has a second dimension here. Because the workspace pins one version across crates/terminator, crates/terminator-mcp-agent, the CLI and the language packages, a bump in Cargo.toml propagates to every member. If you vendor the Rust crates rather than the npm agent, expect to rebuild the workspace on each upgrade; the release profile in Cargo.toml enables cross-crate optimisation, so builds are not instant.

The MIT licence means you can fork and ship, which the README explicitly invites. It does not mean the hosted mediar.ai workflow builder is covered by the same terms; that is a separate product on a separate domain, and nothing in the repository describes its licensing or data handling. No legal advice here, but if you plan to run recorded workflows containing credentials, the repository does not document where those recordings are stored.

Editorial conclusion

Adopt Terminator if your automation target is a Windows desktop and your assistant already speaks MCP, since the install path is a single npx command and the licence is MIT. Skip it if you need macOS or Linux, or if your workflow depends on the Python binding, which the support table marks Partial. Before committing, verify on your own machine that the MCP server starts under your client, that the Chrome extension is permitted in your environment, and which of the crates in the workspace you actually need to build.

Frequently asked questions

Official sources

1. License: MIT
2. mediar-ai/terminator on GitHub
3. Project website
4. README
5. Releases