dsh-browser-control

When an agent drives a browser over CDP, the hardest part is rarely the protocol itself but the login state: modern Chrome refuses to open --remote-debugging-port on the default user-data dir, and a clean instance forfeits Cookies, Login Data, and Local Storage. dsh-browser-control solves this by read-only copying the everyday Chrome profile into an isolated directory, then launching a debug instance from there. The copy is one-directional, lazily synced, port-probed, and never written back, so the CDP driver runs with your real session intact.

The driver layer covers high-frequency web tasks: navigate and return title, final URL, body preview, console logs, pageError, networkError, and a screenshot path; --eval executes arbitrary JS in the page context; --mobile simulates a 390x844 viewport with an iPhone user agent. For canvas-based visualizations (ECharts, D3, WebGL) where a background tab throttles requestAnimationFrame and produces a blank capture, the driver opens a new tab, calls Page.bringToFront, and forces a raf tick to guarantee the frame is rendered. All capabilities are wrapped into six tools: browser_status, browser_launch, browser_kill, browser_open, browser_screenshot, and browser_eval, auto-registered into the agent toolset upon install with no manual CDP orchestration needed.

It suits developers who need authentic login state in automation pipelines: E2E verification, front-end page debugging, capturing auth-gated API responses, or letting an agent perform read-only web exploration and state verification on your behalf.