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.
4.8
6 ratings
CTO @ http://uindow.com | 4x Founder (3 exits)
AI video with native sound, paid per clip. Nothing stored.
A calmer Mac menu bar, one click away.
Enterprise Software. Intelligent Automation. Global Impact.
Comments
19Senior Rails DEV
The real-OS-input bet is the smart part here. Most automation stacks fire synthetic DOM events that sites can fingerprint, so driving genuine cursor movement and keystrokes should sail past a lot of the bot-detection that trips up Playwright and Puppeteer. The "every line sits in plain sight in this repo" stance is a nice trust signal too. One genuine question: how do you keep runs deterministic for CI when you depend on real OS-level input timing rather than synthetic events? Curious whether input-latency flakiness becomes a problem at scale.
CTO @ http://uindow.com | 4x Founder (3 exits)
Automations are written in pure JavaScript, and the SDK itself is deterministic: https://uindow.com/docs/. Issuing trusted events is usually just a matter of using the Chrome DevTools Protocol over WebDriver. For more complex tasks, such as changing the values of HTML <select> elements, the SDK carefully orchestrates emulated mouse events, keyboard input events, and focus control. It's all very reliable. The one thing that perpetually makes any automation "flaky" is that websites change. You can't automatically fix flaky tests, but you can make them easier to rewrite—and that's one of the core values of the Uindow SDK: ease of use.
Some bloke
Since it's a local LLM, have you found using it has a little latency? Soon we will have crazy AI chips for local llms so this is great planning for that
CTO @ http://uindow.com | 4x Founder (3 exits)
The core app is just a deterministic finite-state machine written in JavaScript. In other words, no LLM magic. But if your automations do require a little bit of sentiment analysis or some other task that is beyond regular expressions / deterministic programming, you can use the includer $.llm() method. When this is called, the app automatically downoads a small model (around 3GB), and calls that locally using ollama. For more complex tasks, you can just plug Uindow into your favorite AI agent using the included MCP server: https://registry.modelcontextprotocol.io/?q=uindow
Founder of PodLift - AI podcast content repurposing tool
The real OS-level input approach is genuinely clever — most automation tools rely on synthetic events that modern sites fingerprint and block. What's your experience with headless vs headed mode for tasks requiring CAPTCHA solving? Also curious whether the signed Chromium requirement limits deployment in containerized environments like Docker. This looks like a great fit for AI agents that need to interact with sites defensively designed against bots.
CTO @ http://uindow.com | 4x Founder (3 exits)
The app does not attempt to automate everything. For authentication, captha, and other actions the app simply hands over control back to the user. Also, the app is not meant to be run in a container or CI/CD pipeline although it does have a CLI and it could be executed that way. The goal is to have a programmable / really smart browser, not a Puppeteer alternative that's better at pretending to be human. This is a tool by humans, for humans doing chores, with a little bit of AI https://registry.modelcontextprotocol.io/?q=uindow
The local-first approach is compelling, especially paired with visible source code and native file-dialog support. For teams using this in CI, I’d be interested in how you recommend balancing realistic OS-level input with repeatable tests — e.g., whether recorder output includes enough waits/assertions to keep runs stable across different machines.
CTO @ http://uindow.com | 4x Founder (3 exits)
Although the SDK https://uindow.com/docs/ looks very similar to what you'd expect from a QA tool like Selenium or Puppeteer, this is not a functional testing app. There are no asserts, and no true/false results. Unlike QA tools, which default to a linear A-then-B structure, this app uses a finite-state machine to model interactions. And unlike QA tools, results are not binary (pass/fail), but quite rich: scalars, arrays, tables of data, and even files can be saved for each action run. Finally, each SDK method was written to be resistant to flaky actions. You very rarely need to call "await*" for anything. The included no-code recoder detects page changes and other events and issues await* method calls as needed. But if you don't like the recorder you can always let an AI agent run Uindow or create modules for you using the include MCP server https://registry.modelcontextprotocol.io/?q=uindow
Full-stack developer building WebToolsHub — free browser-based tools for developers. No signup, no ads.
Impressive approach to browser automation! Running on genuine OS-level input instead of synthetic page events is a smart move most automation tools break on sites that detect headless browsers. The prompt injection immunity is what really stands out here, especially for teams running scraping or QA pipelines where untrusted content
CTO @ http://uindow.com | 4x Founder (3 exits)
So here's how prompt injection immunity works. You can obviously write modules by hand (in pure JavaScript). Or you can record them using the incldued no-code recorder. Or you can hand over control to a locally running AI agent via the included MCP server https://registry.modelcontextprotocol.io/?q=uindow Once the automation was written and exported as a module, you no longer need an AI to run it. That makes running automations completely immune to any sort of prompt injection attack - because they are simply deterministic JavaScript code.
The real-OS-input approach is a genuinely clever move. Most automation stacks rely on synthetic DOM events that modern anti-bot systems (like Cloudflare or Akamai) can easily fingerprint and block, so driving a real cursor and actual keystrokes should bypass a lot of those hurdles. That said, from a QA and stability perspective, I have one question regarding CI/CD pipelines: How do you maintain determinism when relying on real OS-level input timing rather than synthetic events? Does input latency flakiness become an issue at scale, and are there any recommended best practices for balancing "realistic input" with "test speed" in a headless environment?
Clever approach. UI feels solid and FTUE is amazing.
Indie maker building TiWOD, a workout interval timer for HIIT, CrossFit and functional training.
Solid niche. What model is powering this under the hood, and how do you handle data privacy for sensitive inputs?
shipping at the intersection of saas and automation
Prompt injection is the thing that actually worries me building browser-automation workflows day to day — most defenses I've seen are prompt-level ("don't follow embedded instructions"), which is brittle. Is your approach architectural (isolating what the model treats as data vs. instructions) or still model-level judgment calls?
Good you can do much better
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.
This is the kind of startup I like seeing. Wishing you and your team plenty of growth. If hiring becomes a challenge, check out Axisure. We connect startups with equity-based talent. axisure.xyz
Full Stack Developer Turning Businesses into AI-Powered Systems | Java, Spring Boot, n8n, GoHighLevel & SaaS Automation
Solid niche. What model are you using does it runs on local LLM?
Solid infrastructure, secure and robust