CDP vs CCU —
your real browser vs a clean one
PilotGentic CDP attaches to your existing Chrome profile — cookies, sessions, extensions, and all. CCU (Claude Code UI / Selenium) starts a fresh, isolated browser. Each is the right tool for different jobs.
The core distinction
Same goal — fundamentally different sessions
PilotGentic CDP
Chrome DevTools Protocol via extension
- ✓ Attaches to your open Chrome tab
- ✓ All cookies and sessions already loaded
- ✓ No login step needed for auth-gated pages
- ✓ Extension HTTP server at localhost:722X/tabs
- ✓ Available natively in Claude Code + PilotGentic
- ✓ Memory, storage, network, Lighthouse — all exposed
CCU / Selenium
Claude Code UI — separate install required
- ✓ Starts a fresh, isolated browser session
- ✓ No state bleed between test runs
- ✓ Consistent, reproducible across environments
- ✓ Cross-browser (Firefox, Safari, Edge)
- ✗ Must re-login for every auth-gated page
- ✗ Not available in Claude Code CLI by default
Why it matters
The session difference changes everything
CDP uses your real session — CCU doesn't
Selenium/CCU starts a clean browser with no cookies, no extensions, no saved state. This means every test against an auth-gated page requires a login step, and any bug that only appears in a real user session (cached data, extension interaction, feature flags set by prior navigation) will be invisible. PilotGentic CDP attaches to your existing Chrome profile — the same tab you're already looking at — so the test environment is identical to what the user experiences.
CDP gives Claude a richer diagnostic picture
Beyond console logs, PilotGentic CDP exposes JS heap memory, localStorage size, service worker count, cookie count, network request waterfall, and Lighthouse scores — all from the live tab. CCU's Selenium driver surfaces what the WebDriver protocol exposes, which is a narrower window. For debugging a production bug you can reproduce in your browser, CDP is the sharper tool.
CCU excels at reproducible, clean-room testing
When you need consistent, repeatable test runs against a public URL — CI integration, regression suites, cross-browser verification — CCU's isolated session is actually the right choice. There's no state bleed between runs, no risk that a cached cookie changes the result. CCU is the right tool when you want clean-room reproducibility; CDP is the right tool when you want to inspect what's actually happening in your live session.
Only CDP is natively available in Claude Code CLI
CCU (Claude Code UI / Selenium harness) is a separate tool that must be installed independently and invoked as a subagent. PilotGentic CDP tools — pilotgentic_extract_console_logs, pilotgentic_devtools_network, pilotgentic_chrome, pilotgentic_console_live — are available immediately to any Claude Code session that has PilotGentic connected as an MCP server. No extra install, no separate process.
Decision guide
Which tool for which task?
Debug auth-gated page
Page only accessible after login. Use CDP — your session cookie is already there.
Regression test suite on public URL
No auth needed, need consistent reproducible results across runs. Clean-room CCU wins.
"There's an error on this tab right now"
You can reproduce the bug in your browser. Run pilotgentic_extract_console_logs — it reads the live tab via the extension.
Cross-browser compatibility check
Need to verify Firefox or Safari behavior. CCU's WebDriver supports any browser; CDP only covers Chrome/Chromium.
Check memory / performance on live tab
Need JS heap usage, DOM node count, or Lighthouse score. Only CDP exposes these; Selenium/CCU doesn't.
Full user flow: login → navigate → assert
Both can do this. Use CDP to test against your real profile with real data; use CCU when you need a reproducible clean run.
Full comparison
CDP vs CCU — feature by feature
| Feature | PilotGentic CDP | CCU / Selenium |
|---|---|---|
| Uses your native browser profile | ✓Existing cookies & sessions | ✗Fresh isolated session |
| No login required for auth-gated pages | ✓Pre-loaded cookies | ✗Must re-authenticate |
| Tests the real user environment | ✓Your Chrome profile, extensions, flags | ~Clean-room only |
| JS console log extraction | ✓Full log entries via extension | ✓Via Selenium driver |
| Network request capture | ✓pilotgentic_devtools_network | ~Limited via driver |
| Memory & storage snapshot | ✓JS heap, localStorage, cookies | ✗ |
| Real-time live console stream | ✓pilotgentic_console_live | ✗ |
| Lighthouse / performance audit | ✓pilotgentic_lighthouse | ✗ |
| Navigate to URL and check render | ✓Via pilotgentic_navigate + CDP | ✓Selenium WebDriver |
| Fill forms programmatically | ✓Via pilotgentic_type + click | ✓Native Selenium strength |
| Multi-step user flow testing | ✓ | ✓ |
| Cross-browser (Firefox, Safari) | ~Chrome/Chromium only | ✓Any WebDriver browser |
| Native Mac app control in same session | ✓AX tree + CGEvent + CDP together | ✗Browser only |
| Available in Claude Code CLI natively | ✓Via PilotGentic MCP | ✗Requires separate CCU install |
Important for Claude Code users
Claude Code CLI does not include CCU natively
The Claude Code CLI ships with no browser automation capability by default. CCU (Claude Code UI) is a separate Selenium-based harness that must be installed and configured independently — it is not part of the standard Claude Code install.
PilotGentic CDP, on the other hand, is available immediately to any Claude Code session once PilotGentic is connected as an MCP server. The tools pilotgentic_extract_console_logs, pilotgentic_devtools_network, pilotgentic_chrome, and pilotgentic_console_live are all ready to use with zero additional setup.
Start debugging with your real browser session
PilotGentic CDP is free, works inside Claude Code, and requires no extra installs. Connect once, debug everything.