# A Browser for Unattended Agents: How chrome-use Logs In and Solves Sliders on Its Own

When an unattended agent starts running, the first hurdle is almost always login. It runs remotely and on a schedule. There is no one nearby to enter a CAPTCHA, and there is no already-logged-in browser for it to reuse. It can only do everything itself: open the browser, enter the username and password, and get past the slider that appears during login.

Ordinary headless browsers cannot pass these three checks. Either they are detected as anti-bot targets right away, or they fill out the form, trigger a slider, and get stuck. chrome-use is built to “let unattended agents complete login by themselves.” This article explains how it gets through these three checks, and what is still unfinished.

The Three Checks

1. Drive a real Chrome without being detected: connect to a real Chrome through CDP, rather than using a headless fingerprint.
2. Enter credentials and log in by itself: work with profile-use to retrieve the account and password from a password vault and fill them into the form.
3. Solve the login slider: solve-slider automatically solves NetEase Yidun gap-puzzle sliders.

The sections below focus on the latter two checks, because they are where unattended flows most often fail.

1. Filling Credentials: Working with profile-use

chrome-use is responsible for opening the browser, locating fields, filling them, and submitting the form. Where credentials come from, and how to avoid leaking them, is handled by the profile-use skill.

profile-use stores account names and passwords in a password vault, rbw, compatible with Bitwarden and self-hosted Vaultwarden. It reads them only once, exactly when they need to be filled, and never writes them into any JSON, logs, screenshots, or chat history. Low-sensitivity fields such as usernames, email addresses, and phone numbers are filled directly. High-sensitivity fields such as passwords are fetched separately and discarded immediately after use.

In a real Zhihu password-login test, profile-use retrieved the phone number and password from the vault by domain name, zhuanlan.zhihu.com. chrome-use filled them into the two input boxes and clicked Log In. During the whole process, the password only passed through memory once. The only thing persisted was a single message saying “filled, redacted.” The submit action triggered a NetEase Yidun slider, which leads directly to the second check.

What About 2FA and Passkeys?

When an unattended agent runs into two-factor verification, remember one rule: do not click native passkey pop-ups. Selection dialogs such as “Bitwarden / system keychain” are operating-system-level windows, not web elements. CDP cannot reach them, so chrome-use cannot click them. There are two workable paths:

• CDP virtual authenticator: Chrome’s CDP has a WebAuthn domain. Register a virtual authenticator and preload credentials, and the passkey ceremony completes inside the browser without ever showing a native window. This is the proper way to automate passkeys.
• Fall back to password + TOTP: Most sites, GitHub sudo confirmation included, keep a “use password” entry point. That is a web link, so chrome-use can click it. The password comes from profile-use, and rbw can also produce the TOTP code.

2. Solving the Slider: NetEase Yidun

After the form is submitted, sites such as Zhihu show a NetEase Yidun gap-puzzle slider. If no human is present, this wall blocks the flow completely. solve-slider, built in since v1.5.34, solves it by itself.

The image below shows the result of the algorithm locating the gap. The green box is the starting point of the puzzle piece, the red box is the detected gap, and the orange arrow is the distance to drag. The red box lands on the notch in the background image, with an error within 1 pixel.

On the official Yidun demo, across 6 fresh loads, each with a newly generated puzzle:

load 1: SOLVED  attempts=1  err=-0.2px
load 2: SOLVED  attempts=1  err=-0.8px
load 3: SOLVED  attempts=1  err= 0.2px
load 4: SOLVED  attempts=1  err=-0.5px
load 5: SOLVED  attempts=1  err=-0.8px
load 6: SOLVED  attempts=1  err=-0.5px

6 out of 6 succeeded, all on the first attempt, and every landing point was within 0.8 pixels of the target. After passing, the Yidun slider turns green and shows a check mark:

How the Three Steps Work

1. Calculate where the gap is. Yidun provides two images: the background image with the notch, and the puzzle-piece PNG with a transparent background. The distance to drag equals the gap’s x-coordinate minus the puzzle piece’s starting point. A common approach is to take a screenshot and then segment the image, but photo textures such as masts, boats, and mountains can be extracted along with the gap, making measurement inaccurate. chrome-use takes a different path: it downloads Yidun’s own two image slices directly by URL and computes in memory. It does not take screenshots, and there is no canvas cross-origin contamination. The algorithm uses grayscale, Sobel vertical edges, and masked normalized cross-correlation. It is written in pure Rust, does not pull in OpenCV, and the binary remains a single file.

2. Drag like a human. This is where most bypass attempts fail. Yidun does not only check where you drag; it also checks how you drag. Constant speed, straight lines, and instant jumps look obviously machine-generated. chrome-use uses humanize to generate human-like drag trajectories with curvature, deceleration, jitter, and variable speed. Across 6 drags, Yidun’s behavior check did not block it once.

3. Closed-loop correction. How far the handle moves and how far the puzzle piece follows can vary by site and rendering mode. Hard-coding the ratio can easily be off by a few pixels. So after one drag, chrome-use first reads the puzzle piece’s actual landing position, calculates the remaining error, and compensates until it is within 1.5 pixels before releasing. No preset ratio or scale is needed; the closed loop converges by itself. Zhihu uses popup mode and includes an entrance animation, and this setup is compatible with that too.

Honestly, It Is Not Finished Yet

• Backend fingerprinting: Yidun also checks account history, IP address, and timing on the server side. Even if the drag is perfect, it may still fail if the account or IP itself looks machine-like. Only real end-to-end runs can determine that.
• Enhanced sliders: icon-shaped puzzle pieces plus decoy shapes in the background, combined with low-contrast photos. The current detector can be pulled off target by decoys, and a more robust method is in progress.
• Click-selection CAPTCHAs: these require clicking specified text or icons in order. They require recognition, localization, and ordered clicks, making them a harder check. Work on this is underway.

But the standard slider check has already been passed. For unattended agents, this is the step from “login immediately gets stuck” to “the flow can keep going by itself.”

Usage

# Install, with no npm and no token
curl -fsSL https://raw.githubusercontent.com/leeguooooo/chrome-use/main/install.sh | sh

chrome-use solve-slider      # Detect the Yidun slider on the current page and solve it automatically
chrome-use solve-slider 5    # Retry up to 5 times on failure, refreshing to get a new puzzle each time

A complete unattended login with profile-use looks like this: profile-use retrieves the account and password → chrome-use fills the form → submit → solve-slider solves the slider. The repository is at github.com/leeguooooo/chrome-use.