LiteLLM 新版本默认关闭了由代理服务器在同一台计算机上执行命令来连接的工具服务器。采用这种方式的开发和运维团队需要在升级时检查工具连接设置。针对首次安装的用户，还新增了通过一条命令启动代理服务器、数据库和管理界面的入门流程。

1. 保留注册信息，阻止执行

2026年10月18日发布的这一版本，核心变化是默认禁用 stdio 方式。MCP 服务器提供模型可用的外部工具，此次调整的方式是通过在代理所在计算机上执行命令来建立连接。它与连接远程服务器的方式不同。

变更提案说明，大多数部署只需要远程服务器，但此前无法关闭本地执行方式。现在，即使保留服务器注册信息，也不会启动进程。远程 HTTP、SSE 服务器不在此次阻止范围内。

2. 阻止信号因请求而异

通过 REST API 查询已禁用服务器的工具列表时，会得到空列表；直接调用工具时，则返回表示拒绝访问的状态码 403 和提示消息。创建或修改同类服务器会被以请求验证错误 422 拒绝。但将现有服务器改为远程连接方式的修改除外。

管理界面会在服务器卡片上添加禁用标记，并在创建和编辑界面中将该传输方式置灰。在现有服务器的详情页等位置，还会显示说明如何重新启用的横幅。

当模型请求指向被阻止的服务器时，可能不会报错，而是在没有工具的情况下成功。因此，判断连接状态时，不应只看请求是否成功，还应检查是否提供了工具。此限制适用于代理，不适用于开发工具包 SDK 的 MCP 客户端。

3. 重新启用需更改进程环境

若要继续使用，需在代理进程环境中设置 LITELLM_ENABLE_MCP_STDIO=true，并重启代理。只有 true 是启用值，不区分大小写，也不区分前后空白。

代理旁的 .env 文件也被视为进程环境。相反，保存在配置文件或数据库中的值会被忽略，并留下警告。通过管理界面或配置更新 API 保存也无法启用。这意味着，是否重新允许工具连接，必须由管理代理运行环境的一方决定。

4. 默认阻止的收益与运维成本

这一变化的好处是默认关闭了在代理计算机上执行本地命令的路径，代价则是现有连接的连续性。依赖原有方式的部署在管理员采取措施前将失去工具，因此有必要在更新工作中加入连接方式检查和环境设置变更。

变更提案还记录了在禁用状态下使用 4 个工作进程运行的验证。在此条件下，40 次界面配置查询均报告已禁用，60 次工具调用均返回 403，且相应工具服务器进程未启动。这是对特定验证条件下行为的确认，并非处理速度提升数据。

5. Docker 启动流程与镜像验证

发行说明介绍，Docker 单命令启动流程可同时启动网关、Postgres 数据库和管理界面。此外，还新增了适用于 Windows 的 PowerShell 启动流程。不过，所提供的原文并未列出实际启动命令和部署文件内容。

说明中的以下代码并非启动命令，而是镜像签名验证示例。LiteLLM 使用 cosign 为镜像签名，并建议采用通过不可变的提交哈希固定公钥位置的验证方式。

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
  ghcr.io/berriai/litellm:v1.106.0

这一版本简化了安装入门流程，同时将是否允许执行本地工具改为由管理员明确决定。