Cdpm

CDPM

한국어 README

CDPM is an MCP server that keeps up to 30 Chrome instances ("slots") on fixed debugging ports and lets any number of Claude Code sessions and subagents drive them by number: *"open slot 3"*, *"log in on slot 1, then fill the form in slot 2"*. Each slot is an ordinary Chrome with its own profile, so logins stick between runs and the browser is the same one you would use by hand.

It grew out of running several Claude agents against logged-in web apps at once, where the hard parts were not clicking buttons but sharing browsers between sessions, keeping them alive, and noticing when Chrome itself got in the way.

Demo

Nine subagents on slots 11-19 (headless). Slots 11-18 each read a GitHub repository page and send the numbers to slot 19 with slot_send; slot 19 waits on slot_inbox, writes a comparison table and opens it. Recorded over CDP from a real run: about 45 seconds of wall time, one frame per pass over the nine slots.

What is different

• Shared, numbered browsers. Slot *N* listens on port 14049 + N and keeps its profile in its own folder. Sessions don't own a browser; they address a slot. Two sessions can work in the same slot on different tabs: commands are queued per tab, so two agents typing into one tab don't interleave. This is covered by an integration test and by a long test where three sessions share one slot for 600 rounds without memory, tab or lock-file growth.
• Plain Chrome over CDP. No Playwright or Puppeteer. Clicks and keys are sent with Input.dispatch*Event, so pages receive trusted events. Chrome is started without --enable-automation, so navigator.webdriver stays false. CDPM never calls Runtime.enable, and every script it runs to read the page lives in an isolated world the page cannot see; snapshots pierce shadow roots. That removes the usual automation fingerprints. It does not get you past rate limits or IP reputation: nine slots searching Google at the same moment will still get a CAPTCHA.
• Survives the boring failures. Slots are started detached, so closing VS Code or Claude Code (even with a process-tree kill) leaves them running. After a reboot, CDPM re-attaches to whatever Chrome answers on the slot ports and re-checks its process ID before touching taskbar icons. If Chrome updates itself while a slot is running (on Windows the update swaps chrome.exe, the old browser can no longer start renderers, and new tabs hang blank), CDPM restarts that slot on the new version and reopens its tabs.
• Agents can coordinate. slot_send / slot_inbox deliver messages addressed by slot and agent name. They are stored on disk, so they survive a Chrome restart, and a waiting agent wakes as soon as one arrives.
• Browser UI the page can't see. JavaScript dialogs are reported and answered with browser_dialog. On Windows, permission bubbles ("access other apps and services on this device", notifications, location) are detected through UI Automation and answered with browser_permission. File pickers triggered by an agent's action are intercepted instead of opening OS windows; a print dialog the page opens is reported right away (the page itself is never modified).

Quick start

npm install -g cdpm-mcp

cdpm install

Restart Claude Code and ask for a slot, for example: *"Open slot 1 with a window and go to github.com."*

Compared with other browser MCP servers

The other two are good tools and the better choice if you need Firefox or WebKit (Playwright) or performance traces and DevTools panels (Chrome DevTools MCP). Their columns reflect their documentation as of October 2026.

Security

Slot ports listen on 127.0.0.1 only, but any process on this machine can connect to them and act with that slot's logged-in sessions. Treat a running slot like an unlocked browser: don't leave sensitive accounts logged in on slots while running software you don't trust. Closed slots keep their profiles on disk (cdpm purge N deletes one).

Details

• Pure CDP. No Playwright, no Puppeteer, no stealth patches. A normal Chrome with a debugging port, driven with real input events.
• Numbered slots. Slot *N* uses CDP port 14049 + N (slot 1 = 14050 … slot 30 = 14079) and its own profile folder. The range avoids the common default 9222; set CDPM_PORT_BASE to move it if something else uses those ports. Ports outside that range are not managed.
• Starts only when asked. No tool ever starts a closed slot except browser_launch. Without a number, the lowest free slot is used.
• Slots outlive their caller. Closing CDPM, Claude Code or VS Code (even when it kills its whole process tree) does not close slot Chrome. Slots end only with browser_close / cdpm close or when you close that Chrome yourself.
• One taskbar button per slot, with a browser-window icon in the slot color and the slot number, pre-corrected so the taskbar shows it pixel-sharp (drawn with the system font via GDI+, so no font files ship in the repo). The window title shows "3번" via Chrome's own window-name feature (pages can't see it).
• Built for many agents. Every tool takes slot explicitly, records who opened each tab and who touched it last, warns (without blocking) when you act on a tab someone else just used, and serializes concurrent commands on the same tab.
• Agents can talk with slot_send / slot_inbox; unread messages are also delivered at the top of every result.
• Status line. cdpm statusline prints live slots as slot-colored numbers; each slot shows the title of the tab last acted on (no agent names; only blank/new tabs left shows just the number): CDPM 1 NAVER 2 Daum. It fits the terminal width (from ccstatusline): titles shrink first, then only numbers, then +N for the rest. A paused slot (slot_pause / cdpm pause) shows its number in dim gray instead of its slot color. A dim CDPM - when none are running. Ending a slot's Chrome yourself (closing its last window on Windows, Cmd+Q on macOS) removes it right away, and titles are read live.
• English for the AI. Server instructions, tool descriptions and tool results are in English to save tokens; Claude is told to answer in the user's language. CLI output is in Korean.
• Leaves the user's PC alone. No window, viewport or zoom changes, and actions that would pop up OS windows are refused (see below).

Works on Windows 11 and macOS. Per-slot icons: taskbar on Windows, Dock on macOS (see "macOS" below).

Linux is experimental: the code paths exist (Chrome lookup, data folder) but it has not been tested on a Linux machine, and there are no per-slot icons.

Requirements

• Node.js 22+
• Google Chrome (found automatically. Windows: registry App Paths, then standard install folders. macOS: /Applications, ~/Applications, then Spotlight. Linux: /usr/bin/google-chrome, google-chrome-stable, /opt/google/chrome/chrome)

Install

Asked to install this? (for Claude / AI agents) Do these steps in order.

1. Check that Node.js 22+ and Google Chrome are installed. If not, tell the user and stop.

2. Run npm install -g cdpm-mcp@latest (also when already installed: this updates it).

3. Run cdpm install (if cdpm isn't found: node "$(npm root -g)/cdpm-mcp/dist/cli.js" install). It registers CDPM with Claude Code and sets up the status line, rules, subagent and permissions; an older git-clone registration is switched to the new location.

4. Do not launch any Chrome slot, ask questions, or explain internals. On success reply with exactly one line in the user's language, e.g. "CDPM installed. Restart Claude Code to use it." (version: cdpm --version). If a step failed, say only which step and why.

npm install -g cdpm-mcp

cdpm install

cdpm install registers CDPM with Claude Code and sets up the status line, the parallel-work rule, the cdpm-browser subagent and the permission allow list in one go. Restart Claude Code afterwards.

Other MCP clients (Cursor, Claude Desktop, ...)

cdpm install only registers with Claude Code. For other clients add it to their mcpServers config (paths from npm root -g):

{

"mcpServers": { "cdpm": { "command": "C:\\Program Files\\nodejs\\node.exe", "args": ["C:\\Users\\ \\AppData\\Roaming\\npm\\node_modules\\cdpm-mcp\\dist\\cli.js"] } } }

On macOS: "command": "/opt/homebrew/opt/node/bin/node", "args": ["/opt/homebrew/lib/node_modules/cdpm-mcp/dist/cli.js"].

• The tools are the same for every client.
• CDPM picks its instructions from the connecting client's name: only claude-code gets the Claude Code specific guidance (spawning subagents with the Agent tool, cdpm-browser). Other clients get a generic rule: give each slot its own subagent if the client has them, otherwise use a different agent name per slot.
• The automatic setup (status line, CLAUDE.md rule, cdpm-browser, permissions) changes ~/.claude, so it only runs when Claude Code connects. Starting CDPM from another client never touches Claude Code's settings.

From a clone (development)

git clone https://github.com/IGELHARINE/CDPM.git

cd CDPM npm install node dist/cli.js install

Update

npm install -g cdpm-mcp@latest

Then restart Claude Code. From a clone: git fetch origin && git reset --hard origin/main and npm install. The MCP registration and status line setting stay as they are. Check the version with node dist/cli.js --version; changes are listed in CHANGELOG.md.

Or just ask Claude: "update CDPM".

What happens automatically

The first time the MCP server starts, CDPM sets these up once, with no extra steps (original files backed up as .before-cdpm):

• the slot display in Claude Code's status line (redrawn every 3 s)
• a rule in the user's CLAUDE.md: when several slots get different jobs, use one subagent per slot in parallel and let each write its own part of the output (Claude follows user instructions more reliably than MCP guidance)
• a CDPM-only subagent cdpm-browser in ~/.claude/agents/: only CDPM tools plus file writing, no CLAUDE.md, so it starts faster (measured on a 3-slot parallel job: median 28.7 s -> 20.6 s, about 37% less usage); same model and effort as the main agent. It uses whatever name CDPM is registered under.
• CDPM tools (mcp__cdpm) in Claude Code's permission allow list (permissions.allow in settings.json), so auto mode's classifier doesn't block typing and filling mid-task. Claude then performs CDPM