real-browser

Launches Chrome Beta with persistent sessions for cookie-preserving web automation via CDP.

6|2|Updated Feb 17, 2026
One-click install
npx skills add https://github.com/dandaka/skills --skill real-browser
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: real-browser
Source: https://github.com/dandaka/skills/tree/main/real-browser
Command: npx skills add https://github.com/dandaka/skills --skill real-browser

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Launch and control real Chrome Beta with persistent login sessions to automate sites that detect automation and to preserve cookies across runs.

Core Features & Use Cases

  • Persistent login sessions with Chrome Beta to keep cookies across runs
  • Multiple independent sessions in parallel without cross-contamination
  • Safe shutdown and restart to preserve state

Quick Start

Launch Chrome Beta with a persistent user-data directory and attach to it via CDP for scripted automation.

Frequently Asked Questions about real-browser

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I automate sites that detect synthetic browser traffic?

Automating sites that detect synthetic traffic requires driving a real Chrome Beta instance with persistent login sessions. This approach maintains stable cookies and avoids triggering anti-automation signals on platforms like LinkedIn and job sites.

How do I keep login cookies persistent across multiple browser automation runs?

Keeping login cookies persistent across runs involves launching Chrome Beta with a dedicated --user-data-dir and attaching via the --remote-debugging-port. You must gracefully shut down the browser after each session to preserve the state for the next run.

Can I run multiple parallel browser sessions without cookie cross-contamination?

Yes, you can run multiple parallel browser sessions without cross-contamination by using separate --user-data-dir directories for each Chrome Beta instance. Each session maintains its own independent login state and cookies when driven via CDP.

What is the correct workflow for attaching Chrome DevTools Protocol to a real browser?

The correct workflow for attaching CDP to a real browser is launching Chrome Beta with --remote-debugging-port and --user-data-dir, then using --cdp and --session flags on every automation command to maintain the persistent connection.

Why do my automated job applications fail session validation on restricted sites?

Automated job applications fail session validation when synthetic automation signals are detected or cookies drop unexpectedly. Using a real Chrome Beta with persistent sessions and proper CDP attachment prevents these validation failures on restricted sites.