cdt

cdt

Enables driving an isolated, already-logged-in Microsoft Edge browser from the shell by reusing your daily Edge's login cookies through a browser-extension bridge.

Category
访问服务器

README

cdt

English | 中文

status platform

cdt drives an isolated, already-logged-in Edge from the shell. It reuses your daily Edge's login cookies through a browser-extension bridge, so the browser it launches is a copy of your daily Edge — signed in, with no passwords involved. It's a thin CLI wrapper over chrome-devtools-mcp, turning its MCP tools into on-demand shell commands.

Why

When an AI agent automates a browser that needs a login, you usually pick between two bad options: let the AI log in itself (it hits CAPTCHAs, 2FA, anti-bot walls), or hard-code credentials into the script (they leak). cdt takes a third path: the AI reuses your daily Edge session. The site sees a normal, already-authenticated browser — no AI login flow, no credentials in code.

Features

  • Reuses your login state — a browser extension reads cookies from your daily Edge; the isolated Edge cdt launches is already logged in.
  • Credentials stay local — cookies travel over a WebSocket/HTTP on 127.0.0.1 into an isolated profile; they're never written to cdt's config or handed to the AI as passwords.
  • Session isolation — each cdt start spins up its own short session id, profile, and Edge process; concurrent AI windows never share a browser.
  • On-demand CLI — every chrome-devtools-mcp tool (navigate_page, take_snapshot, click, fill, …) becomes a shell command, scoped by --session=<id>.
  • Self-cleaningstart auto-reaps dead sessions and hung launches (daemon alive but Edge never came up); a working session is never killed.
  • Default extensions, with settings — whitelisted extensions from your daily Edge (ad blocker, downloader, userscripts…) load into every isolated session already configured, not freshly installed — like opening a new window, not a new browser.
  • Popups suppressed — translate bubble, certificate-error pages, site permission prompts (notifications/location/camera/mic), and the download save dialog are pre-disabled so they don't block automation.
  • AI-skill ready — one command installs the cdt skill into Claude Code and Codex.

How it works

flowchart LR
  DE["Daily Edge<br/>(logged in)"] --> EXT["CDT Bridge extension"]
  EXT -->|WebSocket<br/>127.0.0.1:17890| BR["cdt daemon<br/>(bridge)"]
  CLI["cdt start"] -->|HTTP /inject| BR
  BR -->|puppeteer writes cookies| P[("isolated profile<br/>cdt-&lt;id&gt;")]
  P --> CD["chrome-devtools<br/>(per session)"]
  CD --> IE["isolated Edge<br/>(logged in)"]
  TOOL["cdt tool<br/>--session"] -.->|drives| CD

Four pieces cooperate:

  1. CDT Bridge extension (loaded in your daily Edge) — reads cookies via the chrome.cookies API and pushes them over a local WebSocket.
  2. cdt daemon (bridge/daemon.mjs, resident) — runs the WebSocket server the extension connects to, plus an HTTP server on 127.0.0.1:17891 that cdt calls: /status, /cookies, /inject.
  3. cdt CLI (cdt.ps1) — what you and the AI run. start asks the daemon to inject cookies into a fresh isolated profile, then hands that profile to chrome-devtools.
  4. chrome-devtools-mcp — launches and drives the isolated Edge: one daemon + one browser per session id.

Requirements

  • Windows — the CLI entry point is PowerShell (cdt.ps1); bin/cdt.mjs is a shim that forwards to it. The daemon and extension are portable JS; only the CLI glue is Windows-specific for now.
  • Edge — both your daily browser (the cookie source) and the automation target.
  • Node ≥ 18 on PATH, and the global npm bin directory on PATH (so cdt and chrome-devtools resolve).

Installation (one-time)

In the cdt source directory:

npm i -g .
cdt doctor

cdt doctor installs the chrome-devtools-mcp CLI if missing, detects the Edge path into config, and starts the cdt daemon.

Load the CDT Bridge extension in your daily Edge: run cdt extension to print its path, then edge://extensions → Developer mode → "Load unpacked" → select that directory. The popup should show connected.

Confirm the bridge end-to-end:

cdt doctor     # last line should report "extension connected, cached cookies: N"

(Optional) Deploy the skill to AI tools so the AI can drive cdt:

cdt skills install --targets all     # ~/.claude/skills/cdt, ~/.codex/skills/cdt

Usage

cdt start                                # inject cookies + launch isolated Edge; prints session=<id>
cdt navigate_page --session=<id> --type url --url https://github.com
cdt take_snapshot --session=<id>         # shows your logged-in home → it works
cdt stop --session=<id>

Reuse the session=<id> from cdt start on every following command.

Commands

Command Purpose
cdt start Auto-clean + inject cookies + launch isolated Edge; prints sessionId (not customizable)
cdt <tool> --session=<id> [args] Forward to chrome-devtools (navigate_page, take_snapshot, click, fill, …)
cdt stop --session=<id> Stop session + kill leftover Edge + delete profile + clear marker
cdt sessions list List sessions (alive/orphan) + profiles
cdt sessions clean Remove markers + profiles for dead or hung sessions
cdt config set <k> <v> Set config (executable / httpPort / wsPort / profilesDir / defaultProfile)
cdt extensions list|add|remove Manage the default-load extension whitelist (by name or ID)
cdt doctor Install chrome-devtools CLI + detect Edge + detect default profile + check extension
cdt extension Print extension dir (load at edge://extensions)
cdt skills install|status|update|uninstall Manage the AI skill (--targets claude,codex|all)
cdt uninstall Remove skill + package

Sessions & automatic cleanup

Each cdt start creates an isolated session with a short random id. cdt start first runs an automatic cleanup. A session is reaped when:

  • dead — its chrome-devtools daemon is no longer running; or
  • hung — the daemon is alive but Edge never came up for over 90s (a stuck launch).

Edge is the heartbeat: daemon alive + Edge up = working → left alone; daemon alive + Edge absent past the grace window = stuck → cleaned promptly. A working session is never killed; a hung one doesn't wait for a reboot.

Configuration

cdt config set executable "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
cdt config set httpPort 17891
cdt config set profilesDir "D:\cdt-profiles"
cdt config set defaultProfile "%LOCALAPPDATA%\Microsoft\Edge\User Data"
cdt config list

Read on every run. Config lives in ~/.cdt/config.json. Keys: executable, httpPort, wsPort, profilesDir, defaultProfile (your daily profile — the read-only source for extensions).

Default extensions & popup suppression

Every cdt start copies your whitelisted extensions' code + chrome.storage into the isolated profile, then loads them with install_extension. Because store extensions ship a manifest.key, the loaded ID equals the one in your daily profile, so each extension reads its already-copied chrome.storage — it runs already configured, not freshly installed. This is decoupled from cookies: cookies still arrive via the extension bridge (App-Bound Encryption blocks copying them), while chrome.storage has no such protection and copies cleanly.

Configure the whitelist once by name — cdt resolves it to the stable extension ID:

cdt extensions list                 # show installed extensions (* = whitelisted)
cdt extensions add "AdGuard"        # add by name fragment or 32-char ID
cdt extensions remove "AdGuard"

cdt doctor auto-detects defaultProfile. Popups are pre-suppressed on every session: translate bubble, certificate-error pages (--acceptInsecureCerts), site permission prompts (notifications/location/camera/mic), and the download save dialog — so they don't block click/fill.

Troubleshooting

  • cdt start hangs / prints no session id — Edge launching occasionally stalls (a chrome-devtools-mcp/Edge quirk). Kill it and run cdt start again; the previous hung session is auto-cleaned on the next run.
  • Extension shows disconnected — run cdt doctor (restarts the daemon), or click reconnect in the extension popup. The extension retries in the background.
  • session <id> was not started — you forgot the --session=<id> from cdt start, or the session was auto-cleaned. Run cdt start for a fresh id.
  • A session id collision on cdt start — extremely rare; first decide whether you started that session yourself, only cdt stop it if you did, otherwise just cdt start again.

Status & limitations

cdt is an early-stage, Windows-first tool (the CLI entry point is PowerShell). It wraps chrome-devtools-mcp, an official Google project. Known rough edge: Edge launching can intermittently stall — the automatic cleanup is designed to absorb exactly this.

Uninstall

cdt uninstall                      # removes the deployed skill + the package
Remove-Item -Recurse $HOME\.cdt    # config/profiles/sessions (manual)

Also remove the CDT Bridge extension in daily Edge.

推荐服务器

Baidu Map

Baidu Map

百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。

官方
精选
JavaScript
Playwright MCP Server

Playwright MCP Server

一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。

官方
精选
TypeScript
Magic Component Platform (MCP)

Magic Component Platform (MCP)

一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。

官方
精选
本地
TypeScript
Audiense Insights MCP Server

Audiense Insights MCP Server

通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。

官方
精选
本地
TypeScript
VeyraX

VeyraX

一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。

官方
精选
本地
graphlit-mcp-server

graphlit-mcp-server

模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。

官方
精选
TypeScript
Kagi MCP Server

Kagi MCP Server

一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。

官方
精选
Python
e2b-mcp-server

e2b-mcp-server

使用 MCP 通过 e2b 运行代码。

官方
精选
Neon MCP Server

Neon MCP Server

用于与 Neon 管理 API 和数据库交互的 MCP 服务器

官方
精选
Exa MCP Server

Exa MCP Server

模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。

官方
精选