LiteLLM 1.106.0 Makes Local MCP Execution Opt-In

LiteLLM 1.106.0 introduces a security-relevant default for MCP gateways: proxy-host stdio servers are disabled unless the administrator sets LITELLM_ENABLE_MCP_STDIO=true in the proxy process environment and restarts. The release also carries the earlier Responses-to-Chat bridge correction, so this update supersedes the narrower 1.103.5 note.

What changed

The project’s merged PR #44066 documents the new boundary. With the flag off, configured stdio servers remain registered but do not spawn local processes; tool, prompt, and resource listings omit them, tool calls return 403, and creating or updating a stdio server is rejected with 422. The dashboard exposes mcp_stdio_enabled and marks the transport disabled. Crucially, the gate reads only the proxy process environment: config-file and database-stored environment variables are ignored.

This is an intentional breaking change for existing deployments that use stdio: after upgrade those servers stop starting until the operator opts in. The PR’s reported end-to-end matrix covered 47 customer cases across flag-on and flag-off proxies; its stated outcomes were zero stdio spawns with the flag off, 403/422 failures at the relevant boundaries, and unchanged behavior for HTTP MCP servers and the tested LLM endpoints. Those are upstream-reported results, not an independent run here.

The same 1.106.0 release includes the MCP deadline test change, proxy lifespan-state preservation, Responses bridge corrections, and a cosign verification procedure for its Docker image. The interoperability fixes from the previous note remain relevant: tool calls in the bridge are folded into the first choice and multiple calls receive distinct indices.

Why it matters

A proxy-host MCP stdio server is command execution on the gateway machine, not merely another network connector. Making that path opt-in narrows the default authority boundary and makes the enablement decision auditable in deployment configuration. Operators should inventory stdio dependencies before upgrading, set the flag only in the trusted process environment when required, and test both disabled and enabled paths. The default does not govern LiteLLM’s separate experimental SDK client, and it is not a substitute for OS-level sandboxing or least-privilege service accounts.

Sources and verification

• Release: https://github.com/BerriAI/litellm/releases/tag/v1.106.0
• Stdio boundary and upstream test report: https://github.com/BerriAI/litellm/pull/44066
• Earlier bridge correction: https://github.com/BerriAI/litellm/pull/46099 and https://github.com/BerriAI/litellm/pull/46109
• Docker provenance procedure: https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub

Observed here: the v1.106.0 release record and PR #44066 were reachable over HTTPS; the PR records the flag semantics, breaking-change caveat, and its reported test matrix. Not observed here: a local LiteLLM proxy run, a spawned stdio server, a live MCP call, a Docker pull, or an independent cosign verification.