DEV Community: veilus browser

Connect Claude Code to an Anti-Detect Browser over MCP: Setup, Tools and Guardrails

veilus browser — Sun, 11 Oct 2026 05:30:31 +0000

Veilus runs many browser profiles on one computer, each with its own fingerprint, cookies and proxy. It also ships an MCP server, so an AI assistant such as Claude Code can create those profiles, open them, read their pages, write a Playwright script and put it on a schedule. This post covers the setup, what the assistant can and can't do, and why a few things always stay with you.

Watch the 55-second demo on YouTube: one sentence in Claude Code, three profiles, a script tested on all three, one approval, then a daily schedule.

What you need

Veilus on Windows 10/11 (x64) or macOS on Apple Silicon, from the download page, with the engine downloaded under Settings → Engine & updates.
A paid plan or the 7-day Pro trial. The Free plan (5 profiles on one device) does not include the local API and MCP. See plans and license.
An MCP client: Claude Code, Cursor or Claude Desktop.

Step 1: Turn on the local API

Open API & MCP in the app sidebar and click Turn on port. The port listens only on your own computer. On the same page, create a token. Every MCP call carries it, so treat it like a password.

Step 2: Connect your client

The Veilus app binary has an mcp subcommand that speaks MCP over stdio. The API & MCP page shows a ready-made snippet with the real binary path and your token filled in, so copy it from there. For Claude Code it looks like this:

claude mcp add --scope user veilus -e VEILUS_API_TOKEN=<token> -- "<path to Veilus>" mcp

--scope user makes Veilus available in every folder you open Claude Code in. For Cursor or Claude Desktop, the snippet goes into the client's MCP config:

{
  "mcpServers": {
    "veilus": {
      "command": "<path to Veilus>",
      "args": ["mcp"],
      "env": { "VEILUS_API_TOKEN": "<token>" }
    }
  }
}

Step 3 (Claude Code): add the plugin

Any MCP client can use the tools directly. If you use Claude Code, the Veilus plugin adds four skills that walk through a job step by step and stop at the points where you decide:

claude plugin marketplace add veilus/claude-plugin
claude plugin install veilus@veilus

Restart Claude Code and type /veilus: to see them: campaign for the whole job, script to write and test a script, schedule to plan a schedule and show it to you as a table before creating it, and run to run a script now and explain any failures profile by profile. The plugin is open source on GitHub.

What the assistant can do

As of October 2026 the server has 39 tools. The MCP reference lists every one with its parameters. They fall into five groups:

Group	Tools	What they cover
Profiles and proxies	10	Create up to 50 profiles in one call, launch and stop them, import proxy lists into a pool, test proxies, assign a pool
The page	9	Load a URL in a running profile, read the page as an accessibility snapshot, click and type with real mouse and key events, scroll, wait for an element, attach a file
Scripts	6	Save a Playwright script into Veilus Flow, read it back, trial-run it and read each profile's output
Runs and schedules	7	Run an approved script on many profiles, schedule it, turn schedules on or off, list runs, check how many browsers this computer can run at once
Datasets	7	Tables of per-profile input, such as one account row per profile, that approved scripts read

The page tools act inside a profile that is already running, with its own fingerprint and logins. The assistant does not start a separate browser of its own.

A first request

Describe the job the way you would describe it to a colleague. This is the request from the demo:

Create 3 Veilus profiles named "Demo {n}". Then write a script that opens
https://quotes.toscrape.com/ and prints the first quote and its author.
Test it on those 3 profiles.

The assistant calls create_profiles, opens one profile, uses navigate and snapshot to learn the page, and saves a script with save_script. Then it trial-runs the script with run_script on the three profiles and reads each one's output with get_run_result. If a run fails, it reads the error, fixes the script and saves it again, all before you've looked at anything.

Scripts follow a fixed contract: they connect to the profile's own browser over CDP instead of launching one, and leave the user agent and viewport alone because those belong to the profile. The LLM scripts recipe has the full rules and a minimal correct script.

Approval stays in the app

A script saved by an assistant is not approved. It can be trial-run on up to 3 profiles, but batch runs and schedules accept only approved scripts. To approve it, open Veilus Flow, where the script carries an MCP badge under Pending approval, read the changes or the full source, and click Approve this script.

There is no tool for approving. An approved script runs unattended with your profiles and their logins, and it is a normal Node program with your user's permissions, so it gets the review you'd give a pull request. If the assistant saves a new version later, it goes back to pending.

After that, a second sentence is enough: "I approved it. Schedule it for those 3 profiles every day at 9:00."

Other limits on the assistant

It can create and stop, never delete. No tool deletes profiles, proxy pools, scripts or schedules. The assistant can turn a schedule off, which keeps the schedule and its history.
Existing proxies aren't overwritten by accident. Assigning a pool refuses the whole call if any profile already has a proxy, unless the assistant explicitly forces it.
Expensive calls are rate-limited. Each token can make at most 30 launches, runs, profile creations or proxy imports per 60 seconds.
Stored secrets reach only approved scripts. Profile variables and dataset rows go to approved scripts. A trial run of an unapproved script sees only what was passed to that one call.
evaluate_js is not a sandbox. It runs JavaScript in a logged-in page with that page's rights. Only let an assistant you trust use it on accounts that matter.

Schedules run while Veilus is running and the computer is awake. Turn on Run in background in Settings so closing the window sends Veilus to the tray instead of quitting it.

Try it

Download Veilus, start the 7-day Pro trial in the app, and connect your assistant from the API & MCP page. The MCP page has the overview, and the first-hour walkthrough covers profiles and proxies if you're new to Veilus.

Use Veilus only for accounts you own or manage with permission. See the Acceptable Use Policy.

Originally published on the Veilus blog.

Introducing Veilus: Your First Hour, From Install to a Scheduled Script

veilus browser — Sat, 10 Oct 2026 22:03:22 +0000

The homepage says what Veilus is. This post shows what using it looks like: one sitting, from a fresh install to a script that runs on its own every morning. Each step links to the docs page with the full details.

1. Install, then download the engine

Veilus runs on Windows 10 or 11 (x64) and on macOS 13 or later on Apple Silicon. Get the installer from the download page. Neither Windows nor macOS recognises the publisher on first launch, so you click through one warning: More info → Run anyway on Windows, Open Anyway in Privacy & Security on macOS. The installation guide has the exact steps.

The installer does not include the browser itself. Open Settings → Engine & updates and click Download next to the version marked Latest. That is Veilus's own build of Chromium, and every profile runs on it. The first engine you download becomes active automatically. More about the engine.

2. Create your first profile

Click New profile. Pick the operating system the profile should present. It defaults to your computer's own OS, which is the safer choice: a profile for a different OS has to imitate more, so Veilus warns you if you pick one. Then pick a market under Language & Region, or set the language and timezone yourself, and click Create Profile.

Veilus generates a fingerprint that fits the OS you chose. Click the launch button on the profile's row, keep Browser Only, and a browser window opens with that profile's own fingerprint, cookies and storage.

3. Give it a proxy

Open the profile's panel and go to the Network tab. For one profile, fill in Manual Proxy (HTTP, SOCKS5 or residential) and click Test Proxy. For many profiles, create a proxy pool from a list and assign it. Proxy setup covers both.

This is the step most people trip over. By default Veilus refuses to launch a profile whose timezone doesn't match where its proxy exits, because a US IP with a Vietnam timezone contradicts itself. With a pool assigned, Match to proxy measures the proxy's real exit and proposes the matching timezone. With a manual proxy, set the Timezone yourself on the Fingerprint tab. Save, and the profile launches.

To check the result, tick the profile and click Test. Veilus opens it on a set of fingerprinting test sites, and the Score column shows how many passed.

4. Connect an AI assistant

Everything so far works on the Free plan, which gives you 5 profiles on one device. Automation, schedules and the local API/MCP need a paid plan or the 7-day Pro trial. See plans and license.

Open API & MCP in the sidebar, click Turn on port (it listens only on your own computer), create a token, and copy the ready-made snippet for Claude Code, Cursor or Claude Desktop. The MCP page shows how the assistant works with Veilus. If you use Claude Code, the Veilus plugin adds skills that walk through the job and stop for your decisions.

5. Ask for the job in one sentence

Describe the task the way you'd describe it to a colleague: "Open the first profile, go to the login page of our dashboard, write a script that logs in and prints the account name, and test it."

The assistant opens a real profile, looks at the page, writes a Playwright script and saves it to Veilus Flow. While the script is unapproved, it can trial-run it on up to 3 profiles and read back each profile's output, so it fixes its own mistakes before you look. The LLM recipe shows each tool call along the way.

6. Read it, approve it

Open Veilus Flow. The script carries an MCP badge and sits under Pending approval. Read the changes, or the full source, then click Approve this script. This step exists because an approved script runs unattended with your profiles and their logins. Approval happens in the app, never through the assistant. If the assistant saves a new version later, it goes back to pending. More on reviewing scripts.

7. Put it on a schedule

Ask the assistant to run the approved script every day at 09:00, or create the schedule yourself in the Schedule tab: daily, weekly, every few minutes, a cron expression or a single run. A schedule can target a saved filter instead of a fixed list, so profiles you tag later are included automatically. Schedules.

Schedules run while Veilus is running and the computer is awake. Turn on Run in background in Settings, and closing the window sends Veilus to the tray instead of quitting it.

What the assistant can't do

A few limits are built in. No tool deletes profiles, proxy pools, scripts or schedules: deleting stays in the app, with you. Values you store on profiles, such as logins, only reach scripts you've approved. And at most 16 profile browsers are open at once, counting everything, so a large run waits for a free slot instead of overloading your machine.

Where to go next

Quick start in the docs
Pricing
Telegram for questions, GitHub for bug reports

Originally published on the Veilus blog.

Why We Built Veilus with Rust and Tauri

veilus browser — Sat, 10 Oct 2026 21:59:52 +0000

Veilus opens many browser profiles side by side, each with its own fingerprint and proxy. The desktop app that manages them is built with Tauri 2 and Rust. This post explains why we chose that stack, how the pieces fit together, and what it costs us.

Two Halves: The App and the Engine

Veilus has two parts that are easy to mix up:

The app is what you install. It lists your profiles, edits their fingerprints and proxies, runs automation, and launches browsers. This is the part built with Tauri and Rust.
The engine is the browser each profile runs in: Veilus's own patched build of Chromium. The app downloads it separately and starts one browser per open profile.

[Veilus app: Tauri 2]
  ├── [Interface in the system webview]
  └── [Rust core: profiles, fingerprints, proxies, automation]
        ├── [Profile 1: Veilus's patched Chromium]
        ├── [Profile 2: Veilus's patched Chromium]
        └── [Profile 3: Veilus's patched Chromium]

The engine is Chromium because websites expect a real Chrome-family browser. The app around it had no such constraint, so we could choose the stack we trusted most to stay correct.

Why Tauri

Tauri lets us write the interface with ordinary web technology and put everything else in Rust. The interface runs in the webview the operating system already provides — WebView2 on Windows, WKWebView on macOS — so the app does not carry a second browser just to draw its own windows.

That split suits Veilus:

The app and the engine ship separately. The installer does not include the browser engine; the app downloads Veilus's patched Chromium itself, so the two can be updated on their own schedules.
The state lives in Rust. Profiles, schedules and scripts are kept by the Rust core, and the interface reads and changes them through it.
One core behind every entry point. The local REST API and the MCP server (veilus mcp) ship in the same Rust program as the interface and call into the same core, so your AI assistant works with the same profiles you see in the app.

Why Rust

Memory Safety Without a Garbage Collector

In safe Rust, the compiler rules out use-after-free bugs and data races before the code ever runs, and it does so without a garbage collector. Veilus handles sensitive data — cookies, credentials, fingerprints — so a whole class of memory bugs that cannot reach users is a security property, not just a technical detail.

Concurrency the Compiler Checks

Veilus does many things at once: it launches browsers, watches their processes and runs scheduled scripts across profiles. Rust's type system refuses to compile code that shares data between threads unsafely. It does not prevent every concurrency bug — deadlocks and logic races are still ours to avoid — but in safe Rust a data race is a compile error, not a crash report.

SQLite, Directly

Profiles, schedules and scripts are stored in a local SQLite database on your machine. The rusqlite crate gives the Rust core direct access to it, with no ORM layer in between.

The Trade-offs

Being honest about the downsides:

Fewer ready-made parts. Tauri's ecosystem is still young, so we write more pieces ourselves.
Steeper learning curve. Rust asks more of whoever writes it, and experienced Rust developers are harder to find.
Slower iteration. The compiler is strict, so a change that would be quick in JavaScript can take noticeably longer to get past it. In return, many of the bugs it stops would otherwise have shown up in production.
Two webviews to test. Tauri draws the interface with the operating system's webview, and those behave slightly differently from one system to the next. Veilus ships for Windows and macOS, so the interface has to hold up in both.

Was It Worth It?

For us, yes. The compiler checks what we would otherwise have to remember, the interface stays ordinary web code, and the browser your profiles run in is still Chromium — patched by us, because that is what websites expect. We'll keep writing about what we learn as Veilus grows.

Want to see it for yourself? Download Veilus free — built with Rust, run with confidence.

Originally published on the Veilus blog.