RuboCop MCP/LSP 在 server 模式下立即退出，改走当前进程协议入口

编辑器或 MCP 客户端启动 RuboCop 后立刻收到 EOF，进程退出码却为零，可以检查机器上是否已经运行 RuboCop daemon。普通代码检查能够成功，不代表同一后台通道也能承载 LSP 或 MCP 的持续会话。

RuboCop 1.89.0 的一个明确案例是：启动 daemon 后，--mcp 的初始化请求得不到响应；停止 daemon，同样的客户端初始化恢复正常。--lsp 也存在相同路由问题，但它使用自己的消息帧格式，不能拿 MCP 的 JSON 行请求测试 LSP。

旧启动入口先检查后台服务，再把调用交给 daemon。该通道适合一次性 lint 请求：读取请求、完成检查、返回结果并结束。MCP 和 LSP 需要长时间持有标准输入输出，继续读取初始化后的消息。被转发进一次性通道后，正常结束这一短任务也可能表现为退出零，却没有建立协议会话。

RuboCop 1.90.0 已把 --lsp 和 --mcp 列为在当前进程运行的协议选项；daemon 运行时，这两种调用不会再转发过去。更新依赖并核对编辑器实际执行路径：

bundle update rubocop
bundle exec rubocop --version
bundle exec rubocop --mcp

最后一条启动的是协议端点，应由 MCP 客户端发送消息，不能把普通 RuboCop 文本输出当作握手。还不能升级时，可以先停 daemon，再由原客户端启动端点：

bundle exec rubocop --stop-server

随后检查编辑器配置是否又启动了另一个后台服务，或绕过 Bundler 调用了系统安装的旧版本。使用多个 Ruby 环境时，终端与编辑器可能解析到不同的可执行文件。

验收应分别在 daemon 关闭和开启的条件下完成真实客户端初始化，然后发送后续请求并正常结束会话。保留客户端收发日志；仅进程存活或退出零不能证明协议工作。1.90.0 的路由修补也不会修复任意消息格式错误、标准输出污染或客户端参数错误。若无 daemon 时仍失败，应继续检查这些独立原因，不必反复清缓存。