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.
README
cdt
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.1into an isolated profile; they're never written to cdt's config or handed to the AI as passwords. - Session isolation — each
cdt startspins 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-cleaning —
startauto-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-<id>")]
P --> CD["chrome-devtools<br/>(per session)"]
CD --> IE["isolated Edge<br/>(logged in)"]
TOOL["cdt tool<br/>--session"] -.->|drives| CD
Four pieces cooperate:
- CDT Bridge extension (loaded in your daily Edge) — reads cookies via the
chrome.cookiesAPI and pushes them over a local WebSocket. - cdt daemon (
bridge/daemon.mjs, resident) — runs the WebSocket server the extension connects to, plus an HTTP server on127.0.0.1:17891that cdt calls:/status,/cookies,/inject. - cdt CLI (
cdt.ps1) — what you and the AI run.startasks the daemon to inject cookies into a fresh isolated profile, then hands that profile to chrome-devtools. - 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.mjsis 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
bindirectory on PATH (socdtandchrome-devtoolsresolve).
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 starthangs / prints no session id — Edge launching occasionally stalls (a chrome-devtools-mcp/Edge quirk). Kill it and runcdt startagain; 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>fromcdt start, or the session was auto-cleaned. Runcdt startfor a fresh id.- A session id collision on
cdt start— extremely rare; first decide whether you started that session yourself, onlycdt stopit if you did, otherwise justcdt startagain.
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
百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。
Playwright MCP Server
一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。
Magic Component Platform (MCP)
一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。
Audiense Insights MCP Server
通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。
VeyraX
一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。
graphlit-mcp-server
模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。
Kagi MCP Server
一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。
e2b-mcp-server
使用 MCP 通过 e2b 运行代码。
Neon MCP Server
用于与 Neon 管理 API 和数据库交互的 MCP 服务器
Exa MCP Server
模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。