Claude Code MCP 重複啟動問題規劃報告

目前你的 Claude Code 工作模式會同時保留多個 session，而每個 session 都會依照 .claude.json 中的 mcpServers 設定，各自啟動一份 stdio MCP server。這不是單一 bug，而是目前 stdio transport 的自然結果。

• 每個 Claude session 都是獨立 client process。
• 每個 client process 都會各自啟動 MCP 子程序。
• 因此同一個 MCP（例如 grok-search、DrissionPageMCP、contextweaver）會被重複啟動多份。
• 目前觀察到 Codex 也有相同模式：每個 Codex session 會再各自帶起自己的 grok-search 與 DrissionPageMCP 子程序樹。

1. Claude Code 目前沒有內建跨 session singleton MCP 設定。
2. stdio MCP 在當前設計下是 per-session 啟動。
3. 若要避免重複啟動，必須在 Claude 與真正 MCP backend 之間引入一層輕量 proxy / fabric。
4. 重型 backend 再由平台層常駐管理，而不是由每個 Claude session 自己負責啟動。
5. Codex 目前也呈現相同結構：兩個活躍 Codex session 總共約 809.1 MiB RSS，並且每個 session 都會各自帶起 grok-search 與 DrissionPageMCP 子程序。因此這不是 Claude 專屬現象，而是多個 agent/CLI 對 stdio MCP 的共同模式。

Claude Session ── stdio ──> light proxy ──> local MCP fabric/router ──> shared backend

這個 shared backend 可以：

• 是本機常駐 service（Host-native daemon）
• 也可以是少量選擇性容器化的 backend

因此正確的設計不是「所有 MCP 都放 Docker」，而是：

1. 先定義哪些 MCP 適合共享。
2. 再決定它們共享後要跑在 Host 還是 Docker。
3. Claude 端一律維持 stdio + proxy，減少相容性成本。

Claude Sessions
    │
    ▼
lightweight MCP proxies (host)
    │
    ▼
Local MCP Fabric / Router (host-native daemon)
    │
    ├── Host-native services
    │     ├── contextweaver-daemon
    │     ├── github-pages-daemon
    │     └── drission-orchestrator
    │
    └── Optional containers
          ├── grok-search-daemon
          └── gemini-image-daemon

你提出的顧慮是正確的：如果全 Docker 化，就會帶來每個服務都要額外部署、維護與整合的成本。雖然那不是每個 Claude session 都部署一次，但仍然是每個 backend 一份部署責任。

全 Docker 的問題

• 每個 MCP backend 都要管理映像、環境變數、ports/sockets、logs。
• DrissionPageMCP 類型服務與本機瀏覽器整合困難。
• 會把原本的「MCP 重複啟動問題」擴大成「多服務部署與維運問題」。

因此更合理的順序

1. 先用 Host-native daemon 驗證共享架構是否有效。
2. 只把真正有依賴治理需求的 backend（例如 grok-search、gemini-image-generator）選擇性容器化。

這裡的關鍵不是讓 Claude 直接碰容器，而是讓 Claude 仍然只碰 stdio proxy。

Claude Code -> stdio proxy -> host router/fabric -> containerized backend

責任分工

• Claude session： 只知道自己在呼叫 stdio MCP。
• proxy： 做 request 封裝與回應轉發。
• fabric/router： 做 session_id/request_id 路由、queue、semaphore、隔離。
• backend： 做真正的搜尋、生成、檢索或自動化任務。

這樣的好處

• Claude 端不需要感知 Docker。
• MCP 安裝責任轉移到平台層，而不是每個 session 自己裝。
• 可以逐步替換 backend，而不必改動 Claude 端使用方式。

有，而且在結構上與 Claude 的現象一致，只是目前規模較小。

查詢型 MCP（較安全共享）

• grok-search
• contextweaver

這類通常可以共享 singleton backend，只要做好 request routing 與 rate limit。

有副作用的 MCP（需控併發）

• gemini-image-generator
• github-pages

這類要加：

• semaphore
• 唯一輸出檔名 / 目錄
• request_id 對應

強狀態型 MCP（高風險）

• DrissionPageMCP

這類不要直接共享同一個 browser/tab。應改成：

drission-proxy -> drission-orchestrator -> worker pool -> per-session browser contexts

Phase 1：全 Host 驗證

• 建立 local MCP fabric/router
• 建立 grok-search-proxy、contextweaver-proxy
• 把 grok-search、contextweaver 改成 host-native daemon
• 先觀察 RAM 是否下降、session 共用是否穩定

Phase 2：擴大到副作用型服務

• 納入 gemini-image-generator 與 github-pages
• 加入 semaphore、per-session temp dir、輸出隔離

Phase 3：專門設計 Drission

• 建立 drission-orchestrator
• worker pool / browser contexts / profile isolation

Phase 4：再決定是否容器化

• 若 grok-search 或 gemini-image-generator 真有依賴治理需求，再搬進 Docker
• 不是所有 MCP 一開始就容器化

1. 先改 grok-search：最適合共享，收益高，風險低。
2. 再改 contextweaver：讀多寫少，適合 daemon 化。
3. 之後考慮 gemini-image-generator：需做併發限制。
4. 最後才碰 DrissionPageMCP：一定要做 orchestrator，而不是單例共用瀏覽器。

你要解的不是「要不要 Docker」，而是「如何把 per-session MCP 啟動改成 shared backend」。

最務實的路線不是全 Docker，也不是維持現狀，而是：

1. Claude 端保留 stdio 介面
2. 用 light proxy + local fabric/router 做橋接
3. 先做 Host-native 共享 backend
4. 只有真正需要隔離的服務再選擇性容器化