Frequently Asked Questions

Questions and answers for teams evaluating ClawChrome as the browser layer for agent workflows.

Browser Runtime

#What is ClawChrome?

ClawChrome is an agent browser runtime that lets agents operate a real Google Chrome browser through custom OS control instead of CDP or a Chromium fork.

#Why does real Google Chrome matter?

Modern websites can detect browser forks, CDP automation, and patched stealth layers. ClawChrome runs the real browser, so the browser identity starts from the trusted path.

#Does ClawChrome use CDP?

No. ClawChrome avoids Chrome DevTools Protocol control for the browser workflow. Agents interact through a harness that maps work to real browser input and state.

#Is vision required?

No. Vision is optional. ClawChrome is designed around token-efficient browser state and workflow tools first, with visual inspection available when a task needs it.

Agent Setup

#How does an agent get started?

Use the agent-readable skills.md resources, the CLI, or the docs. The goal is to give the agent enough context to install, connect, recover, and complete real workflows.

#What is the CLI for?

The CLI gives agents and developers a compact path for setup, session work, and debugging without forcing every interaction through verbose browser screenshots.

#Does ClawChrome support MCP?

Yes. ClawChrome supports MCP for harnesses that prefer tool calls. MCP can run locally, remotely, or through a hosted setup depending on the workflow.

#Which agent systems can use it?

Any agent harness that can call the CLI, connect to MCP, or follow the agent-readable docs can use ClawChrome. The integration is not tied to one model provider.

Sessions and Access

#How do agents stay logged in?

ClawChrome supports persistent browser sessions so agents can keep authenticated state across runs when the workflow needs it.

#What is cookie handoff?

The planned Chrome extension workflow lets a user share browser cookies with an agent session when sharing login credentials directly is not appropriate.

#Can cookie access be revoked?

Yes. Cookie handoff is intended to be a controlled workflow where access can be granted for a session and revoked when the work is complete.

#Do I need proxies?

Some workflows do. ClawChrome is designed to work with network setups that look like normal browser traffic from the custom OS layer rather than browser-level proxy flags.

Workflows

#What workflows fit ClawChrome?

Social monitoring, marketing automation, enterprise portal work, ecommerce monitoring, lead research, and other browser workflows where APIs or forked browsers fail.

#Can it handle CAPTCHA-heavy workflows?

ClawChrome reduces avoidable automation signals by using real browser input and real Chrome. Harder challenge workflows can be paired with dedicated unlock services.

#Can I self-host?

Yes. Self-hosted and hosted workflows are both part of the product direction, with the CLI and MCP paths supporting different deployment preferences.

#Where should I ask more questions?

Read the docs, check the agent-facing resources, or join the Discord for workflow-specific help.