Claude Desktop for Linux 中 stdio MCP 服务器双重启动问题全解CCD/LAM 双协调器架构、上游 Bug 报告与用户侧规避方案【免费下载链接】claude-desktop-debianClaude Desktop for Linux项目地址: https://gitcode.com/GitHub_Trending/cl/claude-desktop-debian本篇文章基于 claude-desktop-debian 项目维护的上游报告草案与其配套的技术学习笔记完整解析 Claude DesktopWindows 构建移植至 Linux在聊天面板与 Code/Agent 面板同时激活时claude_desktop_config.json中每个 stdio MCP 服务器被 Electron 主进程重复启动两次的根因、复现手段、日志定位方法、上游 Bug 报告的撰写方式以及 MCP 作者可以立即落地的防御性工作区方案。读完你将能够独立诊断“一个 MCP 两个 node 进程”的现象、向 Anthropic 侧提交可被采纳的结构化报告并为自己的 MCP 服务器加上抗重复启动的保护。问题背景现象、影响面与项目来源claude-desktop-debian 是一个将 Anthropic 官方 Windows Electron 构建重新打包为 Linux 格式.rpm、AppImage、Nix flake 等的非官方项目其打包产物同样带有官方app.asar与配套的 Linux 启动器、--doctor诊断工具见 README.md。在维护过程中社区用户最初由 communitytranslations 在早期构建上报告项目内跟踪为 issue #526发现了一个行为诡异的 bug当 Claude Desktop 会话同时激活经典聊天面板Chat与 Code/AgentCowork面板时~/.config/Claude/claude_desktop_config.json中声明的每一个 stdio MCP 服务器都会被 Electron 主进程派生spawn两次。随后项目维护者直接阅读了 1.5354.0 构建的 bundle 源码确认了根因并写成面向anthropics/claude-code仓库的上游 Bug 报告草案即 546-mcp-double-spawn.md对应项目 issue [#546]。在 上游报告跟踪表 中该报告当前状态为drafted已起草、待提交并已在官方 Linux 构建上一手复现。从用户视角看最直接的诊断信号是打开两个面板后执行ps -ef每个 MCP 服务器都会出现两个进程且它们都是同一个 Electron 主 PID 的子进程。症状识别如何确认你遇到的就是这个 bug在会话同时打开聊天面板与 Code/Agent 面板后ps输出会呈现两批 MCP 子进程批次之间相隔用户打开第二个面板的时长PID PPID(electron) CMD 372628 372434 python ← batch 1 (chat panel) 372633 372434 node 372648 372434 python ... 373288 372434 python ← batch 2 (Code/Agent panel) 373296 372434 node 373327 372434 python关键特征每个 MCP 出现两组进程全部挂在同一个 Electron 主 PID 下杀掉其中一组 PID只会断开对应面板的连接另一组仍然正常工作——它们是两对相互独立的客户端↔服务器连接彼此之间没有故障转移。大部分 stdio MCP 服务器察觉不到自己被双开了——每个实例都只与自己对应的客户端通信退出时也各自清理干净。真正的麻烦只会在 MCP 触及共享外部状态时暴露出来例如绑定同一个 WebSocket 连接向磁盘上同一个文件写入两个实例相互覆盖连接只允许单一连接的外部服务single-connection contract。这类 MCP 会因为重复实例而产生状态竞争、数据污染或连接冲突。根因CCD 与 LAM 两套独立的协调器注册表架构事实每个会话管理器各持有一套 MCP 协调器状态问题发生在Electron 主进程内部。Claude Desktop 主进程中驻留有多个会话管理器Session Manager每个管理器都维护着自己的一套 MCP 协调器Coordinator状态并拥有独立的注册表registry。其中两个管理器会从claude_desktop_config.json派生 stdio MCP正是它们触发了本 bug管理器类IPC 命名空间协调器日志前缀LocalSessionsclaude.web_$_LocalSessions_$_*n2t(ccd)[CCD]LocalAgentModeSessionsclaude.web_$_LocalAgentModeSessions_$_*n2t(cowork)[LAM]此外还存在第三个协调器类SshMcpServerManager日志前缀[SshMcpServerManager]它遵循同样的“每协调器独立注册表”模式但走的是 SSH 传输层因此不会直接造成本地 node 进程的双开。它的存在本身是一个重要线索按协调器隔离状态是有意为之的架构模式而不是一次性疏漏。双重启动为何发生协调器内部去重 vs 跨协调器重复每个协调器在各自的作用域内都是会去重的CCD的启动函数按服务器名维护了一个 per-key 的 promise 队列在 1.5354.0 中为dPt重新派生前会先关闭其全局注册表 MapxX中的旧条目实现同一协调器内的去重LAMLocalMcpServerManager则持有自己的this.connectionsMap通过自己的getOrCreateConnection路径复用已连接条目。问题在于LAM 从不查询 CCD 的注册表。两个协调器各自独立管理自己的派生生命周期各自派生出同一 MCP 服务器的一份拷贝。所以双重启动是当前架构下结构性的必然结果——每个协调器都合法地持有属于自己的连接。净效应是2 个协调器 × N 个已配置 MCP 2N 个进程在较新版本已对照 1.5354.0 验证中两个协调器的传输创建都路由到 Claude Desktop 侧的一个共享传输工厂oPt但该工厂本身不去重其上层的两套 per-coordinator 注册表也并未统一——去重责任依旧落空。日志锚点用日志前缀确认命中本 bug日志前缀跨版本保持稳定在~/.config/Claude/logs/下按前缀检索即可[CCD] [LAM] [LocalMcpServerManager] [SshMcpServerManager]若某次会话同时出现[CCD]与[LAM]前缀说明它命中了两个协调器也就命中了本 bug。针对派生生命周期本身检索以下关键日志行Launching MCP Server: name (CCD spawn entry) Shutting down MCP Server: name (CCD shutdown entry) local-mcp-server-cleanup (LAM cleanup path)每个已声明 MCP 服务器出现两套上述日志就是双重启动的直接诊断信号。次要缺陷utilityProcess.fork 包装器缺少信号升级链在同一段代码中还有第二个值得向上游报告的缺陷信号升级signal escalation处理不对称。child_process.spawn包装器默认分支1.5354.0 中为tFr具备完整的升级序列先结束 stdin等待 2 秒发送 SIGTERM再等待 2 秒最后 SIGKILLutilityProcess.fork包装器built-in-node分支mFr则没有它发送process.kill()默认 SIGTERM等待 5 秒然后再次以相同默认信号调用kill()——没有 SIGKILL 升级。后果是一个忽略 SIGTERM 的内置 Nodebuilt-in-nodeMCP 服务器可能成为泄漏的孤儿 utility 进程永远等不到强制终止。完整复现步骤与预期行为在 1.5354.0 及附近版本的 Linux 主机上可按以下步骤复现Linux 主机运行 Claude Desktop版本接近 1.5354.0在~/.config/Claude/claude_desktop_config.json中至少声明一个 stdio MCP 服务器打开 Claude Desktop开始一个会话打开 Code/Agent 面板并等待其完全初始化原始报告等待了约 5 分钟执行ps -ef | grep server-binary-name。预期结果每个 MCP 服务器 1 个进程。实际结果每个 MCP 服务器 2 个进程且都是同一个 Electron 主 PID 的子进程。应当发生的正确行为无论打开多少个面板claude_desktop_config.json中每个 stdio MCP 服务器条目只应有 1 个进程。资源层面意味着不再有 2 倍内存和 2 倍 stdin/stdout 流量用户层面意味着ps中每个声明服务器只出现一行。修复方向架构级非补丁级报告给出的修复属于架构调整任选其一即可消除重复CCD 与 LAM 共享同一注册表或本地派生工厂在传输层去重或LAM 在进程内运行时通过 CCD 代理其 MCP 流量只有一个协调器拥有派生权。需要特别强调的是stdio MCP 在协议层面就是1:1的——一对 stdin/stdout、一个传输、一个 SDK 客户端。要让一个派生出的子进程同时服务多个 SDK 客户端需要真正的多路复用demuxing工程而非对压缩后 JS 的一次sed修补。这也超出了 claude-desktop-debian 项目“仅做最小 Linux 兼容补丁”的章程详见 docs/learnings/mcp-double-spawn.md 的状态章节。上游报告撰写模板错配与表单字段适配模板错配CLI 模板 vs Desktop 缺陷该报告的目标仓库是anthropics/claude-code但其 bug 模板是为 Claude CodeCLI设计的必填字段如 “Claude Code Version”“Terminal/Shell” 并不直接适用于 Claude Desktop。同仓库中其他 Claude Desktop bug 报告的通行处理方式是版本字段填N/A — Claude Desktop version终端字段选择Other。报告标题[BUG] Claude Desktop 1.5354.0: stdio MCP servers double-spawn from independent CCD/LAM coordinator registries表单字段要点Preflight Checklist勾选三项——已搜索既有 issue未被报告过、单一 bug 报告、使用最新版 Claude CodeWhats Wrong?说明项目背景约 2300 次/天的包下载量3 个版本周期、现象每 MCP 两个 node 进程、均为 Electron 主 PID 子进程、最初症状来源communitytranslations 对更早构建的报告项目内 #526、根因确认过程阅读 1.5354.0 bundle结论与先前文档记录不同CCD 与 LAM 各自持有独立注册表双重启动是结构性的以及次要缺陷utilityProcess.fork无 SIGKILL 升级What Should Happen?每个 stdio MCP 服务器条目一个进程与面板数量无关Error Messages/Logs按上文“日志锚点”一节给出的前缀与关键日志行填写Steps to Reproduce见上文复现步骤Claude ModelNot sure / Multiple modelsIs this a regression?I dont knowLast Working Version留空Claude Code VersionN/A — this is a Claude Desktop issue. Bundle version: 1.5354.0PlatformAnthropic APIOperating SystemUbuntu/Debian LinuxTerminal/ShellOtherAdditional Information符号参考表与提取命令见下节外加两个希望团队一行回答的问题。符号参考表与提取命令对 1.5354.0 验证minified 符号会随上游版本漂移因此报告为每个角色附带了稳定字符串锚点便于跨版本重新定位RoleSymbol in 1.5354.0Stable anchorCCD spawn functionBPtLaunching MCP Server:CCD shutdown functionCPtShutting down MCP Server:CCD per-key promise queuedPtcalled by CCD spawn fn:await dPt(e, async () {...})CCD server registry MapxX.get()immediately preceding the CCD shutdown log lineShared transport factoryoPtbuilt-in-nodeliteral in factory bodyLAM manager classp0A[LocalMcpServerManager]orlocal-mcp-server-cleanupSSH manager classRde[SshMcpServerManager]orssh-mcp-server-cleanuputilityProcess.forkwrappermFrconstructed in shared factorysbuilt-in-nodebranchchild_process.spawnwrappertFrconstructed in shared factorys default branch针对解包后的构建目录如build-reference/app-extracted/.vite/build/index.js报告提供了经过验证的提取命令cd build-reference/app-extracted/.vite/build # CCD spawn function name grep -Pzo async function \K\w(?\(\w*\)\s*\{(?s).{0,800}?Launching MCP Server) index.js | tr \0 \n # Shared transport factory (anchored on the unique built-in-node string) grep -Pzo async function \K\w(?\([^)]*\)\s*\{(?s).{0,400}?built-in-node) index.js | tr \0 \n # All coordinator classes following the per-coordinator-registry pattern grep -Pzo class \K\w(?\s*\{(?s).{0,300}?this\.connections\s*\s*new Map) index.js | tr \0 \n # LAM manager class specifically grep -Pzo class \K\w(?\s*\{(?s).{0,500}?local-mcp-server-cleanup) index.js | tr \0 \n这些正则同时适用于压缩与美化后的 bundle-z使 grep 按 NUL 分隔处理多行\K提取函数/类名锚点字符串保证跨版本可重定位这也是压缩 JS 修补方法论中“锚点选择”思路的延伸。提请上游回答的两个问题报告中特意为团队预留了两个一行即可回答的问题用于决定下游处理路径per-coordinator 隔离状态是有意设计还是各协调器内联创建传输时代遗留的漂移最近抽取出共享传输工厂oPt是去重重构的开端还是顺手清理若 (1) 的回答是“有意设计”下游将把锁文件方案作为受支持的规避路径引导用户若 (2) 是“进行中”则本报告可避免上游重复分析。MCP 作者可立即使用的规避方案在上游修复落地前触及共享外部状态的 MCP 可以自行防御。项目文档给出了两条经过实战检验的原则并已有一个完整参考实现报告作者的baro-voyagerMCP工作区提交cb7bfbb1. 锁文件 陈旧性检查Lockfile staleness check用fs.openSync(wx)创建锁文件并写入 PID随后通过process.kill(pid, 0)验证持有者是否存活。第二个实例发现存在存活的持有者时主动退避back off或回收陈旧锁。回收必须原子化先把新锁写入临时路径再用rename()覆盖陈旧锁——绝不能先unlink()再重新打开否则第三个实例可能趁隙抢得锁。2. 幂等的状态写入Idempotent state writes目标文件/键应从收到的消息载荷message payload解析而不是依赖进程内状态。这样两个实例向同一广播写入时最终落在同一目标上而不会因各自进程内的键相互污染。本仓库排查边界已确认干净的代码路径该 bug 的直接原因位于 Claude Desktop 会话管理器接线中属于上游缺陷无法在本仓库用补丁修复。项目方已系统性地排除了自身代码的嫌疑scripts/patches/ 下的 asar 补丁诊断时共 7 个v3.0.0 rebase 后仅 quick-window 与 org-plugins 幸存——对MCP、mcpServer、LocalSessions、LocalAgentModeSessions、transportToClient、MessageChannelMain、n2t、hZ、oUt等符号零引用scripts/launcher-common.sh——无 MCP 或配置加载逻辑scripts/packaging/ 下的appimage.sh、deb.sh、rpm.sh——无 MCP 或配置加载逻辑scripts/doctor.sh——仅在诊断时读取claude_desktop_config.json做 JSON 校验并统计mcpServers数量、检查 Node.js 版本Node 20 为 MCP 服务器推荐版本不在运行时派生路径上。该 bug 在未修改的上游 asar 上可同样复现即没有任何 Linux 专属初始化参与双加载。MCP 配置说明中另有两点与此相关配置文件位于~/.config/Claude/claude_desktop_config.json务必在退出 Claude Desktop 后再手工编辑该文件因为应用运行期间会按自己的节奏重写配置运行中手工编辑会被下一次写入覆盖。同时注意Claude Desktop 内嵌的 Claude Code CLI 子进程不是本 bug 的原因——它仅在配置映射非空时才收到--mcp-config而本场景下该映射为空。因此不要向anthropics/claude-code提交“CLI 自身双开 MCP”的错误路由报告详见 docs/learnings/mcp-double-spawn.md 的“Routing Upstream Reports”章节。上游报告提交清单与路径Claude Desktop 没有应用内工程 bug 上报通道/bug与/feedback均为惰性无效Help 菜单的 “Get Support” 指向支持聊天队列不对“Troubleshooting” 是自诊断可用来复制Copy Installation ID或Show Logs in File Manager输出附加到 GitHub issue但本身不是上报步骤。因此工程类缺陷需走 GitHub Issues。提交时的完整清单打开anthropics/claude-code仓库的 bug 报告模板将报告草案各小节粘贴到对应表单字段提交把生成的 issue URL 回贴到项目 issue #546 下保证双向可追踪。草稿中同时注明所有上报文本都经过 voice 风格流程aaddrick-voice 体系的一部分后再提交确保跨报告口径一致。这份草案的完整落盘位置是 docs/upstream-reports/546-mcp-double-spawn.md配套的技术细节与规避方案在 docs/learnings/mcp-double-spawn.md全部上游报告的状态与去向汇总在 docs/upstream-reports/README.md。总结一个结构性 bug 的三层应对MCP 双重启动问题最终可以拆成三层来理解与应对诊断层通过ps观察两批同父进程的 MCP 进程、通过日志前缀[CCD]/[LAM]确认命中双协调器就能在一分钟内确认问题上报层由于直接原因在闭源的 Claude Desktop 主进程内任何修复都必须由上游完成——把根因分析、复现步骤、稳定锚点、符号表整理成可提交的表单字段是这个项目已经替社区完成的工作任何人可直接沿用其结构防御层在修复落地前MCP 作者通过锁文件原子回收与幂等状态写入即可让自己的服务器在 2N 进程并存的环境下保持正确行为。【免费下载链接】claude-desktop-debianClaude Desktop for Linux项目地址: https://gitcode.com/GitHub_Trending/cl/claude-desktop-debian创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Claude Desktop for Linux 中 stdio MCP 服务器双重启动问题全解：CCD/LAM 双协调器架构、上游 Bug 报告与用户侧规避方案
Claude Desktop for Linux 中 stdio MCP 服务器双重启动问题全解CCD/LAM 双协调器架构、上游 Bug 报告与用户侧规避方案【免费下载链接】claude-desktop-debianClaude Desktop for Linux项目地址: https://gitcode.com/GitHub_Trending/cl/claude-desktop-debian本篇文章基于 claude-desktop-debian 项目维护的上游报告草案与其配套的技术学习笔记完整解析 Claude DesktopWindows 构建移植至 Linux在聊天面板与 Code/Agent 面板同时激活时claude_desktop_config.json中每个 stdio MCP 服务器被 Electron 主进程重复启动两次的根因、复现手段、日志定位方法、上游 Bug 报告的撰写方式以及 MCP 作者可以立即落地的防御性工作区方案。读完你将能够独立诊断“一个 MCP 两个 node 进程”的现象、向 Anthropic 侧提交可被采纳的结构化报告并为自己的 MCP 服务器加上抗重复启动的保护。问题背景现象、影响面与项目来源claude-desktop-debian 是一个将 Anthropic 官方 Windows Electron 构建重新打包为 Linux 格式.rpm、AppImage、Nix flake 等的非官方项目其打包产物同样带有官方app.asar与配套的 Linux 启动器、--doctor诊断工具见 README.md。在维护过程中社区用户最初由 communitytranslations 在早期构建上报告项目内跟踪为 issue #526发现了一个行为诡异的 bug当 Claude Desktop 会话同时激活经典聊天面板Chat与 Code/AgentCowork面板时~/.config/Claude/claude_desktop_config.json中声明的每一个 stdio MCP 服务器都会被 Electron 主进程派生spawn两次。随后项目维护者直接阅读了 1.5354.0 构建的 bundle 源码确认了根因并写成面向anthropics/claude-code仓库的上游 Bug 报告草案即 546-mcp-double-spawn.md对应项目 issue [#546]。在 上游报告跟踪表 中该报告当前状态为drafted已起草、待提交并已在官方 Linux 构建上一手复现。从用户视角看最直接的诊断信号是打开两个面板后执行ps -ef每个 MCP 服务器都会出现两个进程且它们都是同一个 Electron 主 PID 的子进程。症状识别如何确认你遇到的就是这个 bug在会话同时打开聊天面板与 Code/Agent 面板后ps输出会呈现两批 MCP 子进程批次之间相隔用户打开第二个面板的时长PID PPID(electron) CMD 372628 372434 python ← batch 1 (chat panel) 372633 372434 node 372648 372434 python ... 373288 372434 python ← batch 2 (Code/Agent panel) 373296 372434 node 373327 372434 python关键特征每个 MCP 出现两组进程全部挂在同一个 Electron 主 PID 下杀掉其中一组 PID只会断开对应面板的连接另一组仍然正常工作——它们是两对相互独立的客户端↔服务器连接彼此之间没有故障转移。大部分 stdio MCP 服务器察觉不到自己被双开了——每个实例都只与自己对应的客户端通信退出时也各自清理干净。真正的麻烦只会在 MCP 触及共享外部状态时暴露出来例如绑定同一个 WebSocket 连接向磁盘上同一个文件写入两个实例相互覆盖连接只允许单一连接的外部服务single-connection contract。这类 MCP 会因为重复实例而产生状态竞争、数据污染或连接冲突。根因CCD 与 LAM 两套独立的协调器注册表架构事实每个会话管理器各持有一套 MCP 协调器状态问题发生在Electron 主进程内部。Claude Desktop 主进程中驻留有多个会话管理器Session Manager每个管理器都维护着自己的一套 MCP 协调器Coordinator状态并拥有独立的注册表registry。其中两个管理器会从claude_desktop_config.json派生 stdio MCP正是它们触发了本 bug管理器类IPC 命名空间协调器日志前缀LocalSessionsclaude.web_$_LocalSessions_$_*n2t(ccd)[CCD]LocalAgentModeSessionsclaude.web_$_LocalAgentModeSessions_$_*n2t(cowork)[LAM]此外还存在第三个协调器类SshMcpServerManager日志前缀[SshMcpServerManager]它遵循同样的“每协调器独立注册表”模式但走的是 SSH 传输层因此不会直接造成本地 node 进程的双开。它的存在本身是一个重要线索按协调器隔离状态是有意为之的架构模式而不是一次性疏漏。双重启动为何发生协调器内部去重 vs 跨协调器重复每个协调器在各自的作用域内都是会去重的CCD的启动函数按服务器名维护了一个 per-key 的 promise 队列在 1.5354.0 中为dPt重新派生前会先关闭其全局注册表 MapxX中的旧条目实现同一协调器内的去重LAMLocalMcpServerManager则持有自己的this.connectionsMap通过自己的getOrCreateConnection路径复用已连接条目。问题在于LAM 从不查询 CCD 的注册表。两个协调器各自独立管理自己的派生生命周期各自派生出同一 MCP 服务器的一份拷贝。所以双重启动是当前架构下结构性的必然结果——每个协调器都合法地持有属于自己的连接。净效应是2 个协调器 × N 个已配置 MCP 2N 个进程在较新版本已对照 1.5354.0 验证中两个协调器的传输创建都路由到 Claude Desktop 侧的一个共享传输工厂oPt但该工厂本身不去重其上层的两套 per-coordinator 注册表也并未统一——去重责任依旧落空。日志锚点用日志前缀确认命中本 bug日志前缀跨版本保持稳定在~/.config/Claude/logs/下按前缀检索即可[CCD] [LAM] [LocalMcpServerManager] [SshMcpServerManager]若某次会话同时出现[CCD]与[LAM]前缀说明它命中了两个协调器也就命中了本 bug。针对派生生命周期本身检索以下关键日志行Launching MCP Server: name (CCD spawn entry) Shutting down MCP Server: name (CCD shutdown entry) local-mcp-server-cleanup (LAM cleanup path)每个已声明 MCP 服务器出现两套上述日志就是双重启动的直接诊断信号。次要缺陷utilityProcess.fork 包装器缺少信号升级链在同一段代码中还有第二个值得向上游报告的缺陷信号升级signal escalation处理不对称。child_process.spawn包装器默认分支1.5354.0 中为tFr具备完整的升级序列先结束 stdin等待 2 秒发送 SIGTERM再等待 2 秒最后 SIGKILLutilityProcess.fork包装器built-in-node分支mFr则没有它发送process.kill()默认 SIGTERM等待 5 秒然后再次以相同默认信号调用kill()——没有 SIGKILL 升级。后果是一个忽略 SIGTERM 的内置 Nodebuilt-in-nodeMCP 服务器可能成为泄漏的孤儿 utility 进程永远等不到强制终止。完整复现步骤与预期行为在 1.5354.0 及附近版本的 Linux 主机上可按以下步骤复现Linux 主机运行 Claude Desktop版本接近 1.5354.0在~/.config/Claude/claude_desktop_config.json中至少声明一个 stdio MCP 服务器打开 Claude Desktop开始一个会话打开 Code/Agent 面板并等待其完全初始化原始报告等待了约 5 分钟执行ps -ef | grep server-binary-name。预期结果每个 MCP 服务器 1 个进程。实际结果每个 MCP 服务器 2 个进程且都是同一个 Electron 主 PID 的子进程。应当发生的正确行为无论打开多少个面板claude_desktop_config.json中每个 stdio MCP 服务器条目只应有 1 个进程。资源层面意味着不再有 2 倍内存和 2 倍 stdin/stdout 流量用户层面意味着ps中每个声明服务器只出现一行。修复方向架构级非补丁级报告给出的修复属于架构调整任选其一即可消除重复CCD 与 LAM 共享同一注册表或本地派生工厂在传输层去重或LAM 在进程内运行时通过 CCD 代理其 MCP 流量只有一个协调器拥有派生权。需要特别强调的是stdio MCP 在协议层面就是1:1的——一对 stdin/stdout、一个传输、一个 SDK 客户端。要让一个派生出的子进程同时服务多个 SDK 客户端需要真正的多路复用demuxing工程而非对压缩后 JS 的一次sed修补。这也超出了 claude-desktop-debian 项目“仅做最小 Linux 兼容补丁”的章程详见 docs/learnings/mcp-double-spawn.md 的状态章节。上游报告撰写模板错配与表单字段适配模板错配CLI 模板 vs Desktop 缺陷该报告的目标仓库是anthropics/claude-code但其 bug 模板是为 Claude CodeCLI设计的必填字段如 “Claude Code Version”“Terminal/Shell” 并不直接适用于 Claude Desktop。同仓库中其他 Claude Desktop bug 报告的通行处理方式是版本字段填N/A — Claude Desktop version终端字段选择Other。报告标题[BUG] Claude Desktop 1.5354.0: stdio MCP servers double-spawn from independent CCD/LAM coordinator registries表单字段要点Preflight Checklist勾选三项——已搜索既有 issue未被报告过、单一 bug 报告、使用最新版 Claude CodeWhats Wrong?说明项目背景约 2300 次/天的包下载量3 个版本周期、现象每 MCP 两个 node 进程、均为 Electron 主 PID 子进程、最初症状来源communitytranslations 对更早构建的报告项目内 #526、根因确认过程阅读 1.5354.0 bundle结论与先前文档记录不同CCD 与 LAM 各自持有独立注册表双重启动是结构性的以及次要缺陷utilityProcess.fork无 SIGKILL 升级What Should Happen?每个 stdio MCP 服务器条目一个进程与面板数量无关Error Messages/Logs按上文“日志锚点”一节给出的前缀与关键日志行填写Steps to Reproduce见上文复现步骤Claude ModelNot sure / Multiple modelsIs this a regression?I dont knowLast Working Version留空Claude Code VersionN/A — this is a Claude Desktop issue. Bundle version: 1.5354.0PlatformAnthropic APIOperating SystemUbuntu/Debian LinuxTerminal/ShellOtherAdditional Information符号参考表与提取命令见下节外加两个希望团队一行回答的问题。符号参考表与提取命令对 1.5354.0 验证minified 符号会随上游版本漂移因此报告为每个角色附带了稳定字符串锚点便于跨版本重新定位RoleSymbol in 1.5354.0Stable anchorCCD spawn functionBPtLaunching MCP Server:CCD shutdown functionCPtShutting down MCP Server:CCD per-key promise queuedPtcalled by CCD spawn fn:await dPt(e, async () {...})CCD server registry MapxX.get()immediately preceding the CCD shutdown log lineShared transport factoryoPtbuilt-in-nodeliteral in factory bodyLAM manager classp0A[LocalMcpServerManager]orlocal-mcp-server-cleanupSSH manager classRde[SshMcpServerManager]orssh-mcp-server-cleanuputilityProcess.forkwrappermFrconstructed in shared factorysbuilt-in-nodebranchchild_process.spawnwrappertFrconstructed in shared factorys default branch针对解包后的构建目录如build-reference/app-extracted/.vite/build/index.js报告提供了经过验证的提取命令cd build-reference/app-extracted/.vite/build # CCD spawn function name grep -Pzo async function \K\w(?\(\w*\)\s*\{(?s).{0,800}?Launching MCP Server) index.js | tr \0 \n # Shared transport factory (anchored on the unique built-in-node string) grep -Pzo async function \K\w(?\([^)]*\)\s*\{(?s).{0,400}?built-in-node) index.js | tr \0 \n # All coordinator classes following the per-coordinator-registry pattern grep -Pzo class \K\w(?\s*\{(?s).{0,300}?this\.connections\s*\s*new Map) index.js | tr \0 \n # LAM manager class specifically grep -Pzo class \K\w(?\s*\{(?s).{0,500}?local-mcp-server-cleanup) index.js | tr \0 \n这些正则同时适用于压缩与美化后的 bundle-z使 grep 按 NUL 分隔处理多行\K提取函数/类名锚点字符串保证跨版本可重定位这也是压缩 JS 修补方法论中“锚点选择”思路的延伸。提请上游回答的两个问题报告中特意为团队预留了两个一行即可回答的问题用于决定下游处理路径per-coordinator 隔离状态是有意设计还是各协调器内联创建传输时代遗留的漂移最近抽取出共享传输工厂oPt是去重重构的开端还是顺手清理若 (1) 的回答是“有意设计”下游将把锁文件方案作为受支持的规避路径引导用户若 (2) 是“进行中”则本报告可避免上游重复分析。MCP 作者可立即使用的规避方案在上游修复落地前触及共享外部状态的 MCP 可以自行防御。项目文档给出了两条经过实战检验的原则并已有一个完整参考实现报告作者的baro-voyagerMCP工作区提交cb7bfbb1. 锁文件 陈旧性检查Lockfile staleness check用fs.openSync(wx)创建锁文件并写入 PID随后通过process.kill(pid, 0)验证持有者是否存活。第二个实例发现存在存活的持有者时主动退避back off或回收陈旧锁。回收必须原子化先把新锁写入临时路径再用rename()覆盖陈旧锁——绝不能先unlink()再重新打开否则第三个实例可能趁隙抢得锁。2. 幂等的状态写入Idempotent state writes目标文件/键应从收到的消息载荷message payload解析而不是依赖进程内状态。这样两个实例向同一广播写入时最终落在同一目标上而不会因各自进程内的键相互污染。本仓库排查边界已确认干净的代码路径该 bug 的直接原因位于 Claude Desktop 会话管理器接线中属于上游缺陷无法在本仓库用补丁修复。项目方已系统性地排除了自身代码的嫌疑scripts/patches/ 下的 asar 补丁诊断时共 7 个v3.0.0 rebase 后仅 quick-window 与 org-plugins 幸存——对MCP、mcpServer、LocalSessions、LocalAgentModeSessions、transportToClient、MessageChannelMain、n2t、hZ、oUt等符号零引用scripts/launcher-common.sh——无 MCP 或配置加载逻辑scripts/packaging/ 下的appimage.sh、deb.sh、rpm.sh——无 MCP 或配置加载逻辑scripts/doctor.sh——仅在诊断时读取claude_desktop_config.json做 JSON 校验并统计mcpServers数量、检查 Node.js 版本Node 20 为 MCP 服务器推荐版本不在运行时派生路径上。该 bug 在未修改的上游 asar 上可同样复现即没有任何 Linux 专属初始化参与双加载。MCP 配置说明中另有两点与此相关配置文件位于~/.config/Claude/claude_desktop_config.json务必在退出 Claude Desktop 后再手工编辑该文件因为应用运行期间会按自己的节奏重写配置运行中手工编辑会被下一次写入覆盖。同时注意Claude Desktop 内嵌的 Claude Code CLI 子进程不是本 bug 的原因——它仅在配置映射非空时才收到--mcp-config而本场景下该映射为空。因此不要向anthropics/claude-code提交“CLI 自身双开 MCP”的错误路由报告详见 docs/learnings/mcp-double-spawn.md 的“Routing Upstream Reports”章节。上游报告提交清单与路径Claude Desktop 没有应用内工程 bug 上报通道/bug与/feedback均为惰性无效Help 菜单的 “Get Support” 指向支持聊天队列不对“Troubleshooting” 是自诊断可用来复制Copy Installation ID或Show Logs in File Manager输出附加到 GitHub issue但本身不是上报步骤。因此工程类缺陷需走 GitHub Issues。提交时的完整清单打开anthropics/claude-code仓库的 bug 报告模板将报告草案各小节粘贴到对应表单字段提交把生成的 issue URL 回贴到项目 issue #546 下保证双向可追踪。草稿中同时注明所有上报文本都经过 voice 风格流程aaddrick-voice 体系的一部分后再提交确保跨报告口径一致。这份草案的完整落盘位置是 docs/upstream-reports/546-mcp-double-spawn.md配套的技术细节与规避方案在 docs/learnings/mcp-double-spawn.md全部上游报告的状态与去向汇总在 docs/upstream-reports/README.md。总结一个结构性 bug 的三层应对MCP 双重启动问题最终可以拆成三层来理解与应对诊断层通过ps观察两批同父进程的 MCP 进程、通过日志前缀[CCD]/[LAM]确认命中双协调器就能在一分钟内确认问题上报层由于直接原因在闭源的 Claude Desktop 主进程内任何修复都必须由上游完成——把根因分析、复现步骤、稳定锚点、符号表整理成可提交的表单字段是这个项目已经替社区完成的工作任何人可直接沿用其结构防御层在修复落地前MCP 作者通过锁文件原子回收与幂等状态写入即可让自己的服务器在 2N 进程并存的环境下保持正确行为。【免费下载链接】claude-desktop-debianClaude Desktop for Linux项目地址: https://gitcode.com/GitHub_Trending/cl/claude-desktop-debian创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考