DEV Community: Double CHEN

browser-act CLI Launches Dynamic Proxy — All-in-One Browser Automation for AI Agents

Double CHEN — Wed, 29 Apr 2026 09:19:28 +0000

BrowserAct just released a major feature for browser-act CLI: built-in dynamic proxies.
This is designed for AI Agents and enterprise-grade automation.

Why it matters:

Traditional browser automation requires you to:

Buy from third-party proxy providers ($)
Configure complex URLs and credentials
Handle anti-bot detection (another service)
Solve CAPTCHAs (more fees)
Manage region switching (engineering overhead)

This fragmented toolchain makes automation brittle and expensive.

The browser-act CLI way:

One command. Zero config. Unified billing.

What this means for you:

✅ No proxy juggling — No need to buy from third-party proxy providers or manage credentials. Switch between multiple countries with one command.
✅ Stay undetected — Your automation looks human (stealth fingerprinting + rotating IPs), bypass Cloudflare & DataDome automatically. No more IP bans.
✅ Built for your AI workflow — Run multiple regions in parallel, lower token costs, automatic human handoff when AI gets stuck.

Use Cases:

Cross-border e-commerce price monitoring
Multi-account automation
OpenClaw / Claude Code / Cursor powered data collection
Global testing & compliance validation

This is infrastructure built for the AI era.

Special Offer: ⭐ Star for 500 credits: https://github.com/browser-act/skills
📖 Full docs: https://github.com/browser-act/skills/tree/main/browser-act

Why your scraper plateaus at 5-6 concurrent Chrome instances (and the shared-cookie trap nobody names)

Double CHEN — Thu, 23 Apr 2026 03:35:31 +0000

Someone on r/webscraping this week hit the wall I've seen a dozen projects hit:

"When I try to use multiple pages (tabs) within a single browser instance, Turnstile doesn't load properly on background or non-focused pages. Because of that, I'm forced to run one browser instance per page... I can do like 5 or 6 browsers simultaneously before throttling my CPU, avg about 30+ solves a minute."

5-6 browsers max. 30 solves/min. And — critically — the OP can't go up by using tabs, because tabs break the Turnstile flow.

This is a design constraint hiding as a performance problem. Let's name it.

Why tabs break Turnstile (and other CF challenges)

Cloudflare's Turnstile widget does two things that make it hostile to multi-tab scraping in one Chrome process:

It checks document.visibilityState. A backgrounded tab reports hidden, and the widget's challenge scripts bail out or stall waiting for a visible transition. This is what the OP observed as "Turnstile doesn't load properly on non-focused pages."
Cookies are shared across the entire browser profile. When two tabs both start a CF challenge on the same origin, they race for the same cf_clearance cookie slot. Whichever tab gets focused first writes its token; the other tab's challenge sees a mismatched state and blocks.

One of the replies on the thread nailed this in passing: "cookies are shared in a browser between all tabs, multiple challenges can block each other." That's the full story. Focus matters only as a symptom; the cookie race is the actual collision.

Why "5-6 browsers max" is the wrong number

If you profile what those 5-6 Chrome processes are doing, you'll see:

~200MB RSS each, most of it heap from V8 and the renderer
Two or three render threads spinning waiting for page load / paint
A pool of worker threads for networking and crypto

On a 16GB / 8-core machine you're CPU-bound, not memory-bound, because every page load triggers full Chromium rendering + JS execution for the challenge script — which is deliberately expensive (that's the "work" part of proof-of-work).

So the real ceiling isn't "how many Chrome binaries fit in RAM" — it's "how many concurrent CF challenges can your CPU solve in parallel." At the OP's 30 solves/min on 5-6 browsers, that's ~5 solves/min per browser, or about one every 10-12 seconds. That matches what the challenge takes on a cold profile.

The profile-isolation fix

The escape is not more threads or tabs. It's profile isolation with cached clearance.

The idea:

Pre-warm a pool of Chrome profiles (say, 20 of them) by letting each one solve a CF challenge once and storing the resulting cf_clearance cookie
For each scrape request, pick a profile whose clearance hasn't expired (CF clearances last ~30 min typically)
Run the scrape as that profile. Because the clearance is already present, no challenge runs — you skip the 10-second proof-of-work
When a profile's clearance expires, quietly re-warm it in the background

With this architecture the bottleneck shifts from "CF challenge compute per browser" to "network latency per page," and you can fan out to dozens of concurrent requests.

Real numbers from what I've been running with this pattern:

20 profiles, pre-warmed
~1.5s avg page load on CF-protected targets (from warm clearance)
~8× throughput vs "one browser per page with fresh challenges"

Doing it with browser-act

browser-act is a CLI that manages the profile pool for you — each browser-id is an isolated profile with its own cookies and storage.

# Install:
npx skills add browser-act/skills --skill browser-act

# Create 20 profiles:
for i in $(seq 1 20); do
  browser-act browser create --profile-name "scrape-$i"
done

# Warm each profile by opening the target site once (runs the CF challenge):
browser-act --session warmup browser open <profile-id> https://target.site

# Later, from your scraper, pick a warm profile and run:
browser-act --session scrape browser open <profile-id> https://target.site/page-N
browser-act --session scrape get markdown > page-N.md

The cookies persist on disk per profile, so restarting the scraper doesn't lose clearance.

Things worth arguing about

This doesn't help if your target site rotates challenge policy per request (some bank / gambling sites do). That's a different regime — you need a JS solver loop
20 profiles is about where you hit diminishing returns on a single machine. Past that, put them on separate instances with separate IPs — the cf_clearance cookie is IP-bound
If you only need ~30 pages/minute, the OP's 5-6 browser setup is fine. This matters past ~100 pages/min

Full r/webscraping thread is at optimised chrome? for multi threading. If you're fighting the same ceiling, drop what you've tried — happy to compare.

Selenium keeps getting blocked by Cloudflare? Here's what the fingerprint actually catches (and how to stop triggering it)

Double CHEN — Thu, 23 Apr 2026 03:32:53 +0000

A post on r/webscraping this week asked a question that keeps coming up: "I'm using Selenium through Chrome, need to scrape ~1M pages at ~1s/page, but every request hangs 7-8s on a Cloudflare challenge."

At 7 seconds per page, 1M pages takes 81 days. That's not a rate limit problem. That's a detection problem — and you can't fix it with more threads.

The replies to that post are a goldmine of advice that's mostly right but doesn't explain why. Let's do that.

The actual thing Cloudflare catches

Selenium's ChromeDriver leaks the automation flag in at least three observable ways:

navigator.webdriver === true — exposed by design, WebDriver spec requires it
CDP client signature — ChromeDriver wraps Chrome's DevTools Protocol with a specific RPC pattern that's detectable via timing and order of Target.* calls
Missing browser UI signals — Selenium launches Chrome without certain accessibility/window events that real users always generate

One of the top comments on that Reddit thread summarized it well:

"Selenium operates using a ChromeDriver or a GeckoDriver binary, which any respectable company that doesn't want bots on its website can fingerprint. That doesn't mean Selenium is broken — it just means it was not made for what you're trying to do. Selenium's purpose is automated testing."

That's the right read. Selenium was designed for QA, where you want the site to know you're an automated test. Cloudflare's Bot Management scores those same signals against a human baseline, and the score tanks fast.

What the comments recommend (and what actually works)

Filtered through real use:

Tool	What it does	Catch
`undetected-chromedriver`	Patches the WebDriver flag + CDP strings	Cloudflare pushes updates that re-detect it every few months
`SeleniumBase` CDP mode	Skips ChromeDriver, talks CDP directly to Chrome	Works on most CF sites; still one process per browser
`curl_cffi`	Impersonates a browser's TLS JA3 fingerprint	No JS execution — breaks on sites that hydrate with React
`nodriver` / `zendriver`	Headless-less Chrome with patched CDP	Good for low-scale; resource-heavy at 1M pages
Real Chrome + stealth profile	Actual Chrome binary, persistent profile, cookies survive	What most anti-bot services assume

The last row is what I'll show below — and it's what I've been using.

The actual result

The two captures are from the same browser process, same machine, same IP. The only variable was the fingerprint config.

How I'm doing it now

I've been using browser-act — a CLI that drives a real Chrome with a persistent stealth profile. One command:

# Install (uses the skills package registry):
npx skills add browser-act/skills --skill browser-act

# Open a Cloudflare-protected page in a stealth session:
browser-act --session scrape browser open <profile-id> https://target.site
browser-act --session scrape get markdown > out.md

The profile persists cookies and storage between runs, so the "warm browser" signals (history, localStorage, prior CF cookies) look human. For the r/webscraping OP's scale question (~1M pages), you'd run this with a pool of profile IDs and rotate — but that's a separate post.

Things worth arguing about

If your target is a Cloudflare Turnstile specifically (not the full JS challenge), you're in a different regime — curl_cffi + an injected widget can work, as one of the r/webscraping replies showed
undetected-chromedriver is the cheapest entry point if you already have Selenium code and low volume
Residential proxies matter almost as much as the browser fingerprint. If your IP is a datacenter ASN, nothing in the browser layer saves you

If you're fighting this problem right now, I'd love to hear what site you're on and what's been rejected — happy to compare notes. The full discussion is at r/webscraping's original thread.

🚀 Major BrowserAct CLI Update

Double CHEN — Tue, 21 Apr 2026 08:44:23 +0000

We just shipped 8 new commands that fundamentally change how AI agents handle complex web workflows.

What's New:

✅ Multi-tab navigation
✅ File upload handling
✅ Cookie & session management
✅ Advanced wait strategies
✅ Full-page screenshots
✅ Auto-bypass for Datadome & Human Security

Why This Matters:

If you're building agents that need to navigate multi-step workflows, handle file uploads, or extract data from heavily protected sites — this update eliminates weeks of custom workarounds.

Get Started:

npx skills add browser-act/skills --skill browser-act

📖 Full docs: github.com/browser-act/skills/tree/main/browser-act

Questions? Join our Discord: discord.gg/UpnCKd7GaU

We just shipped browser-act CLI — browser automation without writing code

Double CHEN — Fri, 10 Apr 2026 08:16:15 +0000

We built BrowserAct because we kept running into the same wall: every time we needed to automate something in a browser, we had to start a whole project.

npm init -y
npm install playwright
npx playwright install chromium
# ... now write 25 lines of async/await just to load a page

That's fine when you're building a test suite. Most of the time, you just want to grab a page's content, click something, or take a screenshot — from the terminal, in 30 seconds.

So we built browser-act CLI. Browser automation as terminal commands. No code, no project setup, no framework.

What it looks like

This is a real run. Three commands against Hacker News:

browser-act --session s1 navigate "https://news.ycombinator.com"
browser-act --session s1 wait stable
browser-act --session s1 get markdown

Full page extracted as clean structured markdown — 3 commands, no code written.

Output: 15,547 characters of clean markdown from 78,320 chars of raw HTML. browser-act automatically strips ads, nav bars, and irrelevant noise.

Why not just use Playwright?

Playwright's getting started page: npm init, install, then download ~400MB of browser binaries — before a single line of automation.

	Playwright / Puppeteer	browser-act CLI
First-time setup	npm init + install + ~400MB browser download	`npx skills add browser-act/skills --skill browser-act` — once, global
Navigate + extract content	~25 lines of async/await boilerplate	3 commands
Session state	Manual context management in every script	`--session` persists automatically between commands
Shell integration	Requires Node.js or Python runtime	Pipe output directly to `grep` / `jq` / anything

Playwright is still the right choice for full E2E test suites with parallel workers, trace viewers, and CI pipelines. browser-act CLI is for everything else.

Get started

Install once:

npx skills add browser-act/skills --skill browser-act

Core commands:

# Open a page and extract its content
browser-act --session s1 navigate "https://example.com"
browser-act --session s1 wait stable
browser-act --session s1 get markdown      # clean text output
browser-act --session s1 get html          # raw HTML

# Interact
browser-act --session s1 click 3           # click element by index
browser-act --session s1 input 2 "query"   # fill a field
browser-act --session s1 keys "Enter"

# Capture
browser-act --session s1 screenshot ./out.png

# Stealth mode (bypasses bot detection)
browser-act --session s1 browser list      # pick a stealth profile

Sessions persist between commands — build multi-step automations in shell scripts without managing state yourself.

What people are using it for

Web scraping — no boilerplate, just commands and output
Shell pipelines — get markdown | grep | jq — works with every Unix tool you already use
AI agents — give an LLM direct browser access via CLI commands
Deployment verification — navigate → get markdown → assert expected content
n8n / Make / Zapier integrations — use as a step in no-code workflows

browser-act CLI is live today

→ browseract.com · Free to use · No credit card required

GitHub: github.com/browser-act/skills · AWS Marketplace available

Questions? Drop them in the comments — we read everything.

Looking for Experienced Make.com & Browser Act Creators!

Double CHEN — Thu, 18 Sep 2025 11:48:21 +0000

We’re seeking skilled individuals to:

Build public, non-customizable Browser Act workflows.
Publish them to the Make community via your creator account.

What’s in it for you:

Competitive pay for each workflow.
Keep all platform revenue and consulting fees.
If you’re interested, message me to discuss the details.

Let’s create something amazing together!

BrowserAct —Node Configuration & Best Practices for Web Scraping Automation

Double CHEN — Thu, 18 Sep 2025 08:25:45 +0000

🎯 What is BrowserAct ?

BrowserAct is an innovative web automation platform that combines AI-powered browser interaction with structured data extraction capabilities. It empowers users to create advanced web scraping workflows without any coding skills.

Core Features & Purpose

🚫 No Coding Required: Build workflows with a zero-code interface using visual nodes.
🎯 Precise Data Extraction: Achieve higher accuracy than traditional AI Agents.
🧠 Smart Page Understanding: Leverages AI for better recognition than standard RPA tools.
💰 Cost-Effective: Save up to 90% of costs compared to agent-based scraping solutions.

Revolutionary Advantages of BrowserAct Workflow

Natural Language-Driven Smart Operations

Simplify Workflow Creation: Simply describe your intentions in natural language — no technical expertise required.
AI-Driven Translation: Automatically converts descriptions into precise page operations.
User-Friendly: Business users can easily create, understand, and modify workflows.

Zero Exception Handling Burden

Built-in Smart Fault Tolerance: Automatically handles common exceptions during scraping tasks.
Backup Operation Methods: Single nodes support multiple fallback strategies to ensure success.
Graceful Degradation: Intelligent handling when critical steps fail, minimizing disruptions.

Cost-Effectiveness Breakthrough

90% Cost Savings vs Agent Scraping: Significantly reduce expenses without sacrificing precision.
80% Less Configuration Time: Compared to traditional RPA tools, setup is much faster.
Low Maintenance: Adaptive algorithms reduce the need for manual updates when pages change.

Precision and Intelligence Combined

Higher Accuracy than Agents: Professional extraction algorithms ensure data precision.
Smarter than RPA: AI-powered understanding adapts to complex web pages.
Dynamic Adaptation: Automatically adjusts to changes in page structure, ensuring reliability.

Quick Start Guide：Create Your First Workflow in Minutes

Ready to build your first scraping workflow? Follow these six simple steps:

Create a Workflow - Start with a blank template.
Set Parameters - Configure parameter variables, or delete parameter settings for more flexible data searching
Add Nodes - Click the plus sign below nodes to add new nodes

Use Natural Language: - Describe the operation for each node in plain language (e.g., “Click on the login button”).
Run the Workflow - Click the run button to see scraping results
Data Export - Automatically generate structured data files

Don’t Know How to Set Up a Workflow?

No problem! The BrowserAct Template Marketplace has a wide variety of ready-to-use templates. With just one click, you can experience pre-built workflows tailored to common use cases.

Why Choose BrowserAct?

Experience the Future of Web Scraping Today!

📈 Boost Efficiency: Projects that traditionally take weeks now complete in hours
💰 Reduce Costs: No need for professional development teams - business users can operate directly
🎯 Reliable and Accurate: AI-powered smart scraping with over 95% accuracy rate
🚀 Rapid Iteration: Adjust workflows in minutes when requirements change

🎉 Start Your Zero-Code Data Scraping Journey Now!
Register now and unlock the potential of intelligent data scraping with BrowserAct.

BrowserAct Integration with Make

Double CHEN — Tue, 16 Sep 2025 10:09:21 +0000

BrowserAct App has officially launched on Make, bringing AI-powered automation to your data collection workflows. This integration allows you to supercharge your data processes with intelligent automation capabilities.

DEV Community: Double CHEN

browser-act CLI Launches Dynamic Proxy — All-in-One Browser Automation for AI Agents

Why your scraper plateaus at 5-6 concurrent Chrome instances (and the shared-cookie trap nobody names)

Why tabs break Turnstile (and other CF challenges)

Why "5-6 browsers max" is the wrong number

The profile-isolation fix

Doing it with browser-act

Things worth arguing about

Selenium keeps getting blocked by Cloudflare? Here's what the fingerprint actually catches (and how to stop triggering it)

The actual thing Cloudflare catches

What the comments recommend (and what actually works)

The actual result

How I'm doing it now

Things worth arguing about

🚀 Major BrowserAct CLI Update

We just shipped browser-act CLI — browser automation without writing code

What it looks like

Why not just use Playwright?

Get started

What people are using it for

Looking for Experienced Make.com & Browser Act Creators!

We’re seeking skilled individuals to:

BrowserAct —Node Configuration & Best Practices for Web Scraping Automation

🎯 What is BrowserAct ?

Core Features & Purpose

Revolutionary Advantages of BrowserAct Workflow

Quick Start Guide：Create Your First Workflow in Minutes

Don’t Know How to Set Up a Workflow?

Why Choose BrowserAct?

**BrowserAct Integration with Make**

BrowserAct Integration with Make