The automation software for Windows that also runs JavaScript inside your browser tabs
Almost every list of automation software for Windows stops at the operating system. You get a tool that can click a button in Excel, or a tool that can fill a form in Chrome, but rarely the same tool doing both in one script. Terminator does both because it ships a real Chrome extension, Terminator Bridge, that wires the browser back into the desktop-automation core through a local WebSocket.
The thing nobody else on this SERP ships
The rest of the category is divided into two camps. Desktop tools (Power Automate Desktop, UiPath, AutoHotkey, AutoIt, WinAutomation) drive native Windows controls, file dialogs, and system menus. Browser tools (Playwright, Selenium, browser-based RPA) drive DOMs. Anything that requires both has to either bolt them together with IPC that you maintain, or bounce through the clipboard.
Terminator bolts them together for you. Inside the repository, at crates/terminator/browser-extension/, there is a full Manifest V3 Chrome extension. The service worker keeps a WebSocket open to the Rust core on port 17373. Every time the core receives an execute_browser_script call, it sends the script across that socket, the worker attaches chrome.debugger to the active tab, and runs Runtime.evaluate over the Chrome DevTools Protocol. No DevTools window, no remote-debugging flag, no headless browser.
How the bridge is wired
Four moving parts: your script, the Rust core, the MV3 service worker, and Chrome's debugger API. The same pieces handle every request, in both directions.
execute_browser_script path
One execute_browser_script call, start to finish
The manifest, verbatim
You can audit every permission the extension asks for before you install it. Here is the real manifest, copied from the repo. Seven permissions, and the one doing the work is debugger.
Why each permission is there
- debugger: attach to a tab and call Runtime.evaluate over the Chrome DevTools Protocol.
- tabs: enumerate tabs so the worker can pick the active one to attach to.
- scripting: fallback path via chrome.scripting.executeScript when the debugger path is not available.
- activeTab: scope permissions to the tab the user is currently on.
- webNavigation: know when a page is loading so the worker can re-arm content scripts.
- alarms: keep the MV3 service worker warm with scheduled wake-ups.
- storage: persist attached-tab state and log recent lifecycle events across worker restarts.
The anchor: port 17373
The whole system hinges on one line of Rust and one line of JavaScript. Both reference the same local address.
“Port 17373 is the single seam between native Windows automation and the browser tab. If you can reach it, you can drive both.”
crates/terminator/src/extension_bridge.rs line 32
Verify it yourself
Three greps and a netstat. Everything on this page is checkable against the repo without running an install, and checkable against a live machine after you do.
What a real call looks like
An MCP call that spans the desktop and the browser is one tool call, not two. No inter-process plumbing, no clipboard detour. The selector picks the process, the script runs inside the tab.
Anatomy of the bridge
Eight facts that together make this category of automation software feel different from everything else on the SERP.
Terminator Bridge v0.24.32
Manifest V3 Chrome extension shipped inside crates/terminator/browser-extension. Loads content.js at document_start on every tab and a service worker that talks to the Rust core.
ws://127.0.0.1:17373
The WebSocket address hard-coded as DEFAULT_WS_ADDR in extension_bridge.rs. Rust binds the server, the MV3 worker dials it, and every script crosses that socket.
chrome.debugger
The permission that unlocks CDP from JavaScript. The worker calls sendCommand(tabId, 'Runtime.evaluate', ...) to run your script, skipping the need for a DevTools window.
Your real Chrome session
No fresh profile, no captcha fight, no re-login. The extension runs inside the Chrome you already use, so Gmail, Salesforce, and Google sign-in are already authenticated.
execute_browser_script
MCP tool at crates/terminator-mcp-agent/src/server.rs:7815. Accepts TypeScript, transpiles it, returns up to 30KB of structured data per call. Paired with 34 other desktop-automation tools.
DOM + accessibility tree together
capture_browser_dom and get_window_tree can be called back to back. One pass gives you the UIA tree, the DOM of the active tab, and optionally OCR and omniparser output for icons.
Port collision handling
If another Terminator instance already owns 17373, the new instance starts in proxy_client mode and connects to the existing server. No crashes, no duplicated listeners.
Multi-browser by process name
browser_script.rs normalizes chrome, msedge, edge, brave, opera, and firefox. One MCP call targets whichever Chromium (or Firefox) you happened to have focused.
How you install and see it working
The MCP agent and the extension boot together. You install one npm package, load the extension, and a yellow bar on your tab confirms the debugger is attached. If the bar is missing, scripts fail fast.
Install the MCP agent
npx -y terminator-mcp-agent@latest starts the Rust server and binds 127.0.0.1:17373. On Windows, the server runs as a native process; no Docker, no WSL.
Load Terminator Bridge into Chrome
Drop crates/terminator/browser-extension into chrome://extensions with Developer mode on, or install the packaged crx. The service worker immediately tries to dial the WebSocket.
Watch for the yellow bar
The first time a script runs, Chrome shows 'Terminator Bridge started debugging this browser' at the top of the attached tab. That bar is Chrome's guarantee that nothing is happening silently.
Run a call from your MCP client
In Claude Code, ask it to read a table on the current tab. The agent picks execute_browser_script, ships a few lines of JS, and gets a JSON object back. No screenshot, no OCR, no fresh browser.
Pair it with desktop tools
The next call can be click_element on a Windows-native button, type_into_element on Notepad, or a workflow YAML that alternates the two. The MV3 worker stays connected across the whole session.
Compared to other automation software for Windows
The difference is not in what each tool can click inside a single app. It is in whether your script can cross the OS-to-browser seam without losing session state.
| Feature | Typical Windows RPA | Terminator |
|---|---|---|
| Controls native Windows UI | Yes | Yes, via IUIAutomation COM API |
| Runs JavaScript in your current browser tab | No | Yes, Runtime.evaluate via chrome.debugger |
| Uses your existing logged-in Chrome profile | Usually no, spawns fresh browser | Yes, extension loads into your normal Chrome |
| Chrome DevTools Protocol without DevTools window | No | Yes, MV3 worker attaches chrome.debugger |
| Single tool call spans desktop and browser | No, separate tools | execute_browser_script on terminator-mcp-agent |
| TypeScript scripts transpiled before eval | No | Auto-detected and transpiled server-side |
| Open source extension | Proprietary | MIT, crates/terminator/browser-extension |
| Works across Chrome, Edge, Brave, Opera, Firefox | Usually Chromium only | Normalized by process name in browser_script.rs |
Who lives in the same SERP
All useful tools in their own right. None of them combine UIA with an in-tab Chrome extension the way Terminator does, which is the angle this page is about.
A concrete scenario the rest can't do in one script
You receive an email in Outlook with a link to a Google Sheet. You want to download the PDF version of the sheet, rename the file to include the sender and the first cell's value, and move it into a OneDrive folder based on a rule you read from the sheet itself.
With most automation software for Windows, this is two scripts duct-taped together. With Terminator, it is one MCP session. click_element to open the email, navigate_browser on the Sheet link, execute_browser_script to read row 1 and the sender column, press_key for Ctrl+P to invoke print, type_into_element the new filename into the Save As dialog. One workflow, one session, zero OS-to-browser hand-off.
Because the browser script ran inside the tab you were already looking at, you did not have to log into Google. Because the Save As dialog is a real UIA window, you did not have to screenshot anything.
Where to read the code
Every file referenced on this page is in the public MIT-licensed mediar-ai/terminator repo. Start with the four files below and you have the entire surface of this feature in about 2,000 lines of code total.
Files to read in order
- crates/terminator/browser-extension/manifest.json — declares the MV3 extension and its seven permissions.
- crates/terminator/browser-extension/worker.js — the service worker that opens the WebSocket and attaches chrome.debugger.
- crates/terminator/src/extension_bridge.rs — the Rust side of the WebSocket server, including the port-collision proxy-client fallback.
- crates/terminator/src/browser_script.rs — execute_script, the function that sends one expression and waits for one result.
- crates/terminator-mcp-agent/src/server.rs around line 7815 — the MCP tool definition that your agent calls.
Want to see the bridge run against your own Chrome?
Twenty-minute walkthrough. Bring a workflow that is currently split between a desktop RPA and a browser script. We will collapse it into one Terminator session.
Frequently asked questions
What makes Terminator different from other automation software for Windows like Power Automate, UiPath, or AutoHotkey?
Those tools stop at the OS boundary. They can drive Windows controls, file dialogs, and system menus, but they cannot run a document.querySelectorAll in your browser tab. Terminator ships both a UI Automation backend for native Windows controls and a Manifest V3 Chrome extension called Terminator Bridge, so a single script can click a native Save button and immediately read the DOM of the page it just saved, using the same session state your normal browser already has.
How does the Chrome extension actually talk to the Rust core?
The extension runs an MV3 service worker (crates/terminator/browser-extension/worker.js) that opens a WebSocket to ws://127.0.0.1:17373. The Rust side binds that port via ExtensionBridge::start_server in crates/terminator/src/extension_bridge.rs (line 32: const DEFAULT_WS_ADDR: &str = "127.0.0.1:17373";). When your automation calls execute_browser_script, the Rust core sends a JSON message over the socket, the worker calls chrome.debugger.attach on the active tab, then chrome.debugger.sendCommand(tabId, 'Runtime.evaluate', { expression }), and sends the result back across the same socket.
What permissions does Terminator Bridge request?
Exactly seven, listed in manifest.json: debugger, tabs, scripting, activeTab, webNavigation, alarms, storage. The debugger permission is the one doing the heavy lifting: it lets the extension speak the Chrome DevTools Protocol from code, without a DevTools window ever being open. The content_scripts block matches <all_urls> and runs content.js at document_start on every tab, which is how the bridge knows when a page is ready for scripting.
Why does this matter for AI agents like Claude Code or Cursor?
Because the agent can write one MCP call that spans the desktop and the web, instead of switching tools. Example: 'in Outlook, click the first unread email, then in Chrome, open the attached docs.google.com link and return the table on row 3'. Terminator's MCP tool execute_browser_script (registered in crates/terminator-mcp-agent/src/server.rs line 7815) accepts TypeScript that gets transpiled before execution and runs inside the active Chrome tab. The agent does not have to juggle Playwright plus a separate desktop automation library.
Does this work with my existing logged-in Chrome profile?
Yes, that is the point. The extension is just an extension you install in whatever Chrome profile you already use. Your Gmail, Salesforce, Figma, and every other session is already there. Terminator does not launch a fresh headless browser the way Playwright does by default, so there is no re-login flow, no captcha replay, and no 'your Google account has been blocked from this automated browser' dialog.
What happens if the extension is not installed?
execute_browser_script fails with a clear error. The tool description in server.rs ends with the literal line 'Requires Chrome extension installed.' If the WebSocket client is not connected when a script is sent, the Rust side waits up to 30 seconds for it to reconnect (browser_script.rs, 60 iterations of 500ms) before giving up. During that window the MV3 service worker can be auto-woken by a content-script handshake on page load or navigation.
Is it safe to let an agent run arbitrary JavaScript in my tabs?
It is as safe as you make it. The extension attaches via chrome.debugger, which triggers the standard yellow 'Terminator Bridge started debugging this browser' bar at the top of the tab. You can see every attached tab, and detaching is a single click. The repo is MIT licensed, so the debugger-permission code path is fully readable. Scripts have a 30KB return cap to prevent accidental data firehoses, and the tool description explicitly warns that scripts triggering navigation can be killed before their return statement executes.
Which browsers besides Chrome are supported?
The bridge targets any Chromium browser that accepts the extension: Chrome, Edge, Brave, Opera. Firefox is detected by process name in browser_script.rs and falls back to the same extension loaded in Firefox. The browser is normalized by process: msedge or edge map to msedge, chrome maps to chrome, and so on, so one codebase handles all of them.
Can I verify the port binding on my own machine?
On Windows, run netstat -ano | findstr :17373 | findstr LISTENING. You will see a single process owning the port: that is either terminator-mcp-agent or a Rust process embedding the crate. If another process already owns the port, the extension falls back to proxy-client mode and connects to the existing server instead of binding its own (extension_bridge.rs line 644, start_proxy_client).