uindow

Uindow - AI browser immune to prompt injections

Uindow drives a real, signed Chromium/Electron browser with genuine OS-level
input - actual cursor movement, real keystrokes, and native file dialogs rather
than synthetic page events. It runs entirely on your own machine and your own
network, and every line of code it executes sits in plain sight in this repository.

Automate it three ways:

• No code - build automations in the integrated editor and record complex workflows without writing code.
• From any AI assistants - Uindow ships a local
  MCP server, so Claude, Cursor, VS Code, or any
  MCP-compatible client can list, create, and run automation modules directly.
  See Control Uindow from AI assistants.
• Write automations in pure JavaScript - Use the integrated development environment to write, test, and
  debug automations with ease. Auto-completion, code healing, JavaScript parsing, and linting are all built in.

Running Uindow

Option 1 - npx (recommended)

One command to fetch the CLI and launch the app:

npx -y @uindow/cli@latest app:start

Other lifecycle commands:

npx @uindow/cli app:status  # check whether the app is running
npx @uindow/cli app:stop    # stop the app

Option 2 - Run locally from source

Clone the repository and launch the app directly from source.

git clone https://github.com/uindow/uindow.git uindow
cd ./uindow/
npm install
npm start

What actually runs on your machine

Both options do the same minimal thing: they fetch the official, signed Electron
binary (only if it isn't already on your machine) and tell Electron to load
dist/run.js. That's the whole story - a genuine, trusted, signed Electron runtime
executing code that is clearly visible to you in this repository. Nothing is hidden,
obfuscated, or pulled in behind your back.

Option 3 - Install prebuilt binaries

Prefer a packaged installer?

We build signed binaries for macOS, Windows, and Linux directly from the dist
source, and host them on the Releases
page (current and older versions).

The build tooling lives in this repository and does exactly one job: it archives
the dist folder into app.asar. You can audit it and reproduce the build yourself.

In order to use the app, create a free account at Uindow
and follow the on-screen instructions.

Control Uindow from AI agents (MCP)

Uindow exposes a local Model Context Protocol server,
so any MCP-compatible client can drive web-automation agents directly.
The server communicates over stdio securely and is launched on demand by the AI assistant.

Requirements: Node.js 18+ with npx on your PATH.

npx -y @uindow/cli@latest mcp

Quick reference

Uindow provides a 1-click connector for the most popular AI assistants.

Go to Uindow ➤ AI assistants ➤ Connect

JetBrains AI Assistant

Go to Settings ➤ Tools ➤ AI Assistant ➤ Model Context Protocol (MCP) and click
Add, then paste the JSON. In the same dialog, set the scope to Global rather than
project-scoped so the server is available in every project you open, then click Apply
to start it.

{
    "mcpServers": {
        "uindow": {
            "command": "npx",
            "args": ["-y", "@uindow/cli@latest", "mcp"]
        }
    }
}

Any other AI Assistant

Most remaining AI assistants accept the same object under mcpServers. Look for the config file
in your home directory (~/.<client>/...) rather than the one in your project root - the
home-directory copy is the global one:

{
    "mcpServers": {
        "uindow": {
            "command": "npx",
            "args": ["-y", "@uindow/cli@latest", "mcp"]
        }
    }
}

Point the AI assistant at the command npx with arguments -y @uindow/cli@latest mcp.

If your AI assistant requires an explicit transport field, use "type": "stdio".

Verifying the connection

Run the launch command by hand first - it's the fastest way to separate "Uindow is broken"
from "the AI assistant can't start it":

npx -y @uindow/cli@latest mcp

A stdio server prints nothing and blocks. A silent, hung terminal means it started
correctly; press Ctrl-C and go back to your AI assistant. Any stack trace you see here is the
real error your AI assistant was swallowing.

Then confirm the scope took: open the AI assistant from a different directory than the one
you configured it in, and check that Uindow's tools are still listed. If they vanish, the
entry landed in a project-local config.

Troubleshooting

Server works in one project but not another. Classic scope problem - the entry is
project-local. In Claude Code, claude mcp list from the other directory will come up
empty; re-add with --scope user. In Gemini CLI, re-add with -s user. In Cursor and VS
Code, move the entry from .cursor/mcp.json or .vscode/mcp.json to ~/.cursor/mcp.json
or the user-profile mcp.json.

spawn npx ENOENT / server never starts in a GUI app. Desktop apps don't inherit your
shell's PATH, which bites anyone using nvm, asdf, or Volta. Run which npx (where npx
on Windows) and put the absolute path in command.

Config saved, nothing happened. Most desktop AI assistants only reload MCP config on a full
restart - quit the app entirely (macOS: Cmd+Q; Windows: quit from the tray icon) rather
than closing the window.

Tools missing after adding the server. Check the root key against the table above:
servers for VS Code, context_servers for Zed, mcp_servers in TOML for Codex,
mcpServers everywhere else. A wrong key is ignored silently in most AI assistants.

Duplicate or shadowed entries. Several AI assistants resolve project config ahead of global
config, so an old project-local uindow entry will silently win over the new global one.
Delete the stale entry rather than editing both.

Server connects but tools aren't used. In Claude Code, MCP tools are deferred behind
tool search by default and loaded on demand, so they may not appear in an upfront tool
list. Ask for a Uindow tool by name, or set "alwaysLoad": true on the server entry to
load its tools at session start.

Where to look next. claude mcp list and /mcp (Claude Code), Output panel ➤ MCP
Logs (Cursor), Output ➤ MCP (VS Code), ~/Library/Logs/Claude/mcp*.log or
%APPDATA%\Claude\logs\mcp*.log (Claude Desktop).

Command-line interface

You can run Uindow from any CI/CD pipeline or command-line interface.

npx -y @uindow/cli --help

Alternatively, you can use node dist/bin.js --help instead of npx @uindow/cli --help
for a faster response.

  USAGE
    $ npx @uindow/cli <command> [options]

  AVAILABLE COMMANDS
    $ npx @uindow/cli mcp          Run MCP server
    $ npx @uindow/cli app:docs     Fetch SDK documentation
    $ npx @uindow/cli app:start    Start application
    $ npx @uindow/cli app:stop     Stop application
    $ npx @uindow/cli app:status   Check application status
    $ npx @uindow/cli list         List agents
    $ npx @uindow/cli create       Create agent
    $ npx @uindow/cli update       Update agent
    $ npx @uindow/cli delete       Delete agent
    $ npx @uindow/cli start        Start agent
    $ npx @uindow/cli stop         Stop agent
    $ npx @uindow/cli status       Check agent status
    $ npx @uindow/cli execute      Execute code in agent
    $ npx @uindow/cli logs         Fetch agent logs

  OPTIONS
    --help      Help menu for a specific command
    --version   Package version

All commands that specify the @return tag in their description return valid
JSON-formatted values.

Creating modules

Most people never open the SDK. There are three ways to build a module - reach for
them in this order:

1. Record it - zero learning curve. Open the integrated recorder and use the
   browser exactly as you normally would: point, click, scroll, upload and download
   files. The recorder turns your actions into JavaScript for you - deterministically,
   without any AI, and instantly. What you see is what you get.

2. Let an AI agent write it - MCP. Want something more involved? Hand control to
   your local AI agent over MCP and have it author the module on your behalf. Describe
   the outcome and let it produce the code for you. You're always in control of your
   automations, and you can use the included IDE to debug your code.

3. Write it yourself - SDK. Ff the recorder and the AI-driven approach both come up
   short, go straight to the source:

   1. Visit the Uindow SDK Reference
   2. Download the sample module and import it into Uindow
   3. Experiment with the dollar-sign methods - the integrated editor has auto-complete,
      code hints, formatting and linting

For most people the learning curve is zero - the recorder is all you'll ever touch.
And if you decide to go pro, it stays shallow: the SDK is there when you want it, not
before.