chrome-devtools-mcp-mux

1つのChromeインスタンスを複数のMCPクライアントで共有します。各クライアント（例：個別のClaude Codeセッション）は、独自の独立したタブセットを持ちながら、すべて同じブラウザとプロファイルで実行されます。

解決する問題

chrome-devtools-mcp はChrome DevToolsをMCPクライアントに公開します。1つのクライアントに対しては完璧に動作しますが、2つのクライアントが同時に接続すると（2つのClaude Codeウィンドウ、Claude CodeとGemini CLIなど）、タブが競合してしまいます。list_pages はすべてを表示し、select_page は競合し、new_page は間違ったウィンドウに作成されてしまいます。

cdmcp-mux はクライアントと chrome-devtools-mcp の間に配置され、単一のChromeを実行し続けながら、各接続に独自の独立したタブセットを提供します。

インストールと設定（初回のみ）

git clone <this-repo> chrome-devtools-mcp-mux
cd chrome-devtools-mcp-mux
npm install
npm run build
npm link           # exposes `cdmcp-mux` on PATH

次に、各MCPクライアントの .mcp.json に以下を記述します：

{
  "mcpServers": {
    "chrome": { "command": "cdmcp-mux" }
  }
}

以上です。最初に接続したクライアントが共有デーモンを自動的に起動し、後続のクライアントはその同じデーモンに接続します。

動作確認方法

上記の設定で2つのMCPクライアントを起動します。それぞれでモデルに以下のように指示します：

1. new_page を使用して異なるURLを開く。

2. list_pages を実行する。

各クライアントは自分のページのみを表示するはずです。ホスト上で cdmcp-mux status を実行すると、デーモン内の両方のコンテキストを並べて確認できます。

録画ビデオ付きの完全なスクリプトデモについては、demo/ を参照してください。

環境変数（オプション）

デバッグ

すべて帯域外で行われます。muxはMCPクライアントにデバッグツールを公開しません。

ログは ~/.local/state/cdmcp-mux/mux.log に保存されます。

仕組み

flowchart TB
    subgraph clients["one process per MCP client"]
      direction LR
      C1["Claude Code #1"] -- "stdio (MCP)" --> S1["cdmcp-mux shim"]
      C2["Claude Code #2"] -- "stdio (MCP)" --> S2["cdmcp-mux shim"]
    end

    subgraph shared["shared — auto-spawned on first connect"]
      direction TB
      D["mux daemon<br/><i>per-connection context table</i><br/>(socket fd → ctxId → owned pageIds)"]
      U["chrome-devtools-mcp subprocess<br/><code>--experimentalPageIdRouting</code><br/><code>--userDataDir <fixed></code>"]
      B["Chromium<br/><i>one instance, one profile</i>"]
      D -- "stdio (MCP)<br/>rewrite + filter" --> U
      U -- "CDP" --> B
    end

    S1 -- "unix socket" --> D
    S2 -- "unix socket" --> D

    classDef client fill:#e3f2fd,stroke:#1976d2
    classDef shim fill:#fff3e0,stroke:#f57c00
    classDef core fill:#f3e5f5,stroke:#7b1fa2
    classDef browser fill:#e8f5e9,stroke:#388e3c
    class C1,C2 client
    class S1,S2 shim
    class D,U core
    class B browser

各MCPクライアントは独自の cdmcp-mux シムを生成します（これが .mcp.json の仕組みであり、クライアントごとに1つの子プロセスが生成されます）。シムはクライアントのstdioとUnixソケット間の純粋なバイトパイプです。最初に接続したシムが共有デーモンを自動生成し、後のシムはそれに接続します。デーモンは、1つの --userDataDir を持つ1つのChromiumを駆動する1つの chrome-devtools-mcp サブプロセスを所有します。

Unixソケット接続ごとに1つの新しい BrowserContext（独立したCookie、localStorage、WebSocket）が作成されます。デーモンは標準の chrome-devtools-mcp と全く同じツールスキーマをアドバタイズします。pageId と isolatedContext はクライアントから見えるものからは取り除かれ、デーモンの接続ごとの所有権テーブルに基づいて、すべての tools/call で再注入されます。アトミック性はアップストリームの --experimentalPageIdRouting を使用しているため、異なるコンテキストからの同時呼び出しが互いに干渉することはありません。クライアントが切断されると、そのタブは閉じられ、ブラウザコンテキストは破棄されます。

開発メモ

このプロジェクトは、ライブの会話要件に基づき、Claude-Codeエージェントによって単一の作業セッションで最初から最後まで記述されました。完全なテスト計画は機能的な正確性を重視して階層化されており（58テスト、約19秒、すべて合格）、マルチプレクサーはVNC自動化された再現環境を通じて視覚的に実証されました。

PRDとテストの対応については DEMO.md を参照してください。完全なエージェント開発ログ（要件の発見、アーキテクチャの反復、テストの階層化、ビデオデモの3つのテイク）については demo/README.md を参照してください。

テスト

# requires a Chromium binary; the smoke/e2e tests need it
CDMCP_MUX_CHROMIUM=/usr/bin/chromium npm test

期待値：8 files, 58 tests, all passing。

リリース

CIはNode 22および24を使用して main へのすべてのプッシュとPRで実行され、ビルド、型チェック、および58個の全テストスイート（実際のChromiumスモークテストおよびバイナリe2eテストを含む）を実行します。

公開は .github/workflows/publish.yml を通じて自動化されており、GitHubリリースが公開されると実行されます：

1. package.json の version を更新し、コミットし、v<version> としてタグ付けします。

2. gh release create v<version> --generate-notes を実行します。

3. ワークフローがビルド、テストを行い、npm provenance（GitHub OIDC経由で署名、ワークフローには id-token: write が必要）を使用して npm publish を実行します。

NPM_TOKEN は唯一必要なリポジトリシークレットです。パッケージは publishConfig.provenance: true で公開されるため、--provenance フラグは暗黙的に適用されます。このリポジトリが npmjs.com で 信頼できるパブリッシャー として登録されると、NPM_TOKEN シークレットは完全に削除できます。

ライセンス

Apache-2.0 — LICENSE を参照してください。アップストリームの chrome-devtools-mcp と同じです。