Devcdp

DevCDP

Real Chrome DevTools access for an AI assistant, over MCP. Your assistant reads the console, watches the network, queries the DOM, resolves source maps, sets breakpoints and inspects live variables — so it can tell you why something broke instead of guessing from a pasted error.

Works with any assistant that speaks MCP, and with any web app: nothing about a particular framework, product or company is built in.

74 tools — see docs/TOOLS.md for the full reference, generated from the server itself, and docs/PERFORMANCE.md for measured token costs and how to lower them.

What it does

Four things it is careful about

It never fakes success. A breakpoint that cannot bind says bound: false and explains why. A body Chrome has discarded says so. A capture from a pause that has already resumed is marked stale. Every failure is {ok: false, code, message, hint} with the next action named.

It tells you where its knowledge ends. Chrome cannot replay console history to a debugger that attaches later, so attaching reports exactly that rather than presenting an empty buffer as "no errors".

It cannot be stranded. Every call into the page is bounded on our side — Runtime.evaluate's own timeout is enforced by the renderer, which is useless when the renderer is what is stuck. A page wedged in an infinite loop fails in seconds with the recovery path named, and DevCDP will abort the runaway script and retry by itself.

It never leaves your app frozen. Breakpoints capture what you need and then resume on their own. A pause held deliberately is still released after maxPauseMs, and everything is cleaned up on disconnect.

Install

Requirements: Node 18+, Chrome, and an MCP-capable assistant.

Pick whichever fits your client. All of them run the same server on your machine; nothing is hosted.

Any MCP client, from npm. Add to the client's MCP config:

{ "mcpServers": { "devcdp": { "command": "npx", "args": ["-y", "devcdp"] } } }

On native Windows some clients need "command": "cmd", "args": ["/c", "npx", "-y", "devcdp"].

Claude Code, as a plugin (server plus a skill that tells Claude when to reach for which tool):

/plugin marketplace add Dayananda-D/DevCDP
/plugin install devcdp@devcdp

Cursor: , or add the JSON above to ~/.cursor/mcp.json.

Gemini CLI, as an extension that also carries the usage guidance:

gemini extensions install https://github.com/Dayananda-D/DevCDP

opencode: opencode mcp add, or in opencode.json:

{ "mcp": { "devcdp": { "type": "local", "command": ["npx", "-y", "devcdp"], "enabled": true } } }

Codex (CLI, desktop, VS Code extension), as a plugin:

codex plugin marketplace add Dayananda-D/DevCDP

VS Code: Install in VS Code, or run MCP: Add Server, choose NPM Package, and enter devcdp. Copilot CLI: /mcp add with command npx -y devcdp. DevCDP is in the official MCP Registry; the picker inside VS Code shows GitHub's curated subset of that registry, which is a separate listing.

From source, with the setup wizard that also writes usage guidance into your assistant's instructions file: see Setup, next.

Then launch Chrome with remote debugging (debug-chrome.bat, or chrome --remote-debugging-port=9222 --user-data-dir=<a separate profile>), open your app, and describe the bug.

Setup

1. node initialize_MCP.js      (or double-click initialize_MCP.bat)
2. Fully quit and reopen your assistant
3. Double-click debug-chrome.bat, open your app
4. Describe the bug

The wizard detects installed editors, writes the right config shape for each, and drops a launcher. It never overwrites a config file it cannot parse — it prints the snippet to paste instead — every write is atomic with one timestamped backup, and duplicate registrations from older installs are removed. That path is covered by 23 tests, because getting it wrong damages your machine rather than just failing.

Settings

Everything is optional. Ask the assistant to run devcdp_settings to see the effective values and where each came from, or devcdp_settings_init to write an annotated file you can edit.

Files are merged, later winning, so an install-wide baseline can be overridden per project:

<install>/devcdp.settings.json   or  <install>/settings.json
<cwd>/.devcdp/settings.json
<cwd>/devcdp.settings.json

then DEVCDP_* environment variables, then tool arguments. Comments and trailing commas are tolerated.

docsRoot and sharedMemoryDir are the two worth setting: the first lets the assistant learn your domain vocabulary, the second is what makes "the team's fixes accumulate" actually true.

Multiple sessions at once

Several agents can debug on one machine safely. Each session claims a tab in a registry under ~/.devcdp/registry/, taken atomically so two processes cannot win the same tab. A session that dies stops heartbeating and its claim is reaped, so nothing stays wedged.

• A new session gets an unclaimed tab; if all are taken it opens its own — on the page you wanted, not blank, and it says why.
• Reloading your assistant briefly overlaps two server processes, so a short grace period lets the departing one release its tab and the new one simply reattaches.
• browser: 'new' launches a separate Chrome, own port and profile.
• window: 'new' gives the session its own browser window.
• sessions_list shows which session holds which tab.

Knowing which tab is in use

Every claimed tab carries a 1px edge border and a small identity chip. The border tells you who is driving:

• breathing blue glow — DevCDP is working
• still, green — it has handed control to you
• still, red — something failed

Three states, three colours, and each colour means exactly one thing regardless of how many sessions are running. Sessions are told apart by the chip text and by their own Chrome tab group — not by hue, which would turn the border into a puzzle when the only thing worth knowing at a glance is whether the tab is waiting for you.

Tabs the app opens for itself — window.open, target="_blank", a detail screen in its own window — are marked and held too, labelled "opened tab". devtools_status lists them under tabsAppOpened, with the call that switches to one.

The indicator cannot outlive the session that drew it. A normal finish — you close the assistant, it disconnects, the session ends — removes the border immediately. If the server is killed and never gets to clean up, the overlay notices it has stopped hearing from its session and removes itself within ownerTimeoutMs (45s), taking the tab out of its group with it. Either way, a border on screen means a session is genuinely there. For one left behind by an older build, node scripts/sweep.mjs clears any that no live session owns (--dry to look first).

Status messages appear as translucent, self-fading toasts. A ring follows pointer activity and a ripple marks each click, so an agent's actions are followable. When the debugger pauses, Chrome's own "Paused in debugger" banner appears — browser UI, adding nothing to your page.

None of it can intercept a click: the whole layer is pointer-events: none except the confirmation button during a handover, which is 91×24px. There is a test that fires real mouse events through it.

Real Chrome tab groups are drawn by the bundled extension, which puts each session's tabs in a titled blue group. Chrome will not let a tool install an extension for you — branded Google Chrome ignores --load-extension ("not allowed in Google Chrome", from its own log) and does not expose Extensions.loadUnpacked over the debugging port — so pick one of:

• No manual step: point chromePath at Chromium or Chrome for Testing. Those builds allow the switch, so the extension loads itself and grouping just works. If such a binary is already on your machine, devtools_status tells you where it is.
• Branded Chrome: install it once — chrome://extensions → Developer mode → Load unpacked → select extension/. The debug profile is persistent and shared by debug-chrome.bat and DevCDP's own launcher, so once is once.

devtools_status.tabGrouping reports whether the tab is actually in a group, and when it is not, whether that is because no extension is installed or because an installed one failed — with the error. Nothing else depends on grouping: the border, the chip and window:'new' all work without it.

Working with the assistant

You do not have to wait to be asked. Click, type, choose — it is recorded, and the assistant reads it with session_get_user_actions: which element, which option, and the value you typed.

Ctrl+Shift+D in the tab hands control to you explicitly. That also opens the window in which typed values are captured, so "use this reference" reaches the assistant. Outside that window values stay private, and password-like fields are redacted either way.

When the assistant needs something only you can do, it asks on the page and waits for the I've done it ✓ button. That button is the only unambiguous signal — Chrome reports automation input as trusted too, so an action cannot be proven human, and the tools say so rather than pretending.

A typical investigation

"The save button does nothing. Find the exact line."

1. devtools_connect — attaches, claims the tab, marks it
2. source_search("save") — finds the handler by content, no path needed
3. debugger_set_breakpoint(file, line) — replies bound: true
4. the click is triggered
5. debugger_get_capture — scope, console and network from the pause, one call
6. the answer is a value that was actually observed, at a line that actually exists

Breakpoints resume themselves, so the click that tripped one still completes.

When you know the function but not the file — which is the usual case with a framework — debugger_set_breakpoint_at_function("app.store.save") asks the engine where that function was defined and breaks at its first statement. Searching for a name in source text is unreliable: a function assigned as Foo.bar = function cannot be found by searching "bar: function", and that query happily returns unrelated methods on other classes instead.

A capture stays small even on a framework object graph: the variable that matters is printed, and anything too large says what it is ("constructor", 77747 bytes expanded) so you can read just the part you want with debugger_evaluate_at_frame.

Security

The launcher uses a separate Chrome profile, so your everyday browsing is untouched, and leaves web security enabled — disabling it hides exactly the cross-origin failures you would be debugging.

Typed values are not recorded unless you enable it or are actively collaborating, and password-like fields stay redacted regardless.

Remote debugging gives full control of the browser profile to anything that can reach the port. Use the debug profile for development, not for personal accounts.

Layout

index.js                 entry point
server.js                shim for older configs pointing here
src/
  core/      config, context, buffers, structured errors, tool registry
  cdp/       connection, target selection, session claim registry, launching
  browser/   the injected in-page agent
  debug/     source maps, scope expansion
  store/     learned-memory store
  tools/     one module per tool group
extension/               companion extension for Chrome tab groups
plugins/devcdp/          Claude Code plugin: manifest, launcher, skill (generated)
server.json              MCP Registry manifest; must agree with package.json
scripts/gen-docs.mjs     regenerates docs/TOOLS.md and the plugin skill
docs/TOOLS.md            full tool reference (generated)
docs/PUBLISHING.md       how each marketplace listing is made and kept current
test/
  validate.mjs           offline checks, no browser needed
  installer.test.mjs     the setup wizard, against real files
  integration.mjs        real Chrome against a fixture app
  fixture-app/           small app with a staged bug and a real source map
BACKLOG.md               every defect found, its fix, and what remains

Working on DevCDP

node scripts/call.mjs <tool> '<json>'   call one tool, see the exact response and its cost
node scripts/mcp-probe.mjs             the same thing over real MCP, raw JSON-RPC

Breakpoints, logs, and the traps this codebase has already fallen into: docs/DEBUGGING.md.

Tests

npm run validate          offline checks
npm run test:installer    the setup wizard
npm test                  all three suites
npm run docs              regenerate the tool reference

199 checks. The integration suite attaches to a page that has already finished loading, because that is the case the previous version got wrong. npm run validate fails if docs/TOOLS.md is out of date, so the reference cannot drift.

Troubleshooting

Tools not appearing — fully quit the assistant (tray/menu, not just the window) and reopen. Re-run the wizard if still missing.

"Chrome is not reachable" — launch via debug-chrome.bat, then check http://localhost:9222/json/version. Only one Chrome can own a port.

A breakpoint never fires — debugger_list_breakpoints and look at bound. An unbound breakpoint reports why.

Support the project

DevCDP is free and MIT-licensed, built and maintained by one person. If it saved you a debugging afternoon, sponsoring on GitHub keeps it moving. Teams wanting a hosted setup, shared learned memory across engineers, or an onboarding workshop can open an issue to start the conversation.

Privacy and license

DevCDP runs locally and sends nothing anywhere except to the MCP client you connected it to: PRIVACY.md. MIT licensed: LICENSE.

A selector finds nothing — dom_list_frames; the content may be in an iframe. Retry with frame: 'all'.

Empty console or network right after attaching — expected. Capture starts at attach; page_reload replays the page with DevCDP watching.

The page stops responding — its main thread is blocked, usually a loop in app JS. page_interrupt aborts the running script; reloading will not free it.

A tab is unavailable — sessions_list shows which session holds it.