Should Host-spawned stdio MCP servers run under SandboxPolicy?

[yihanzhu]

#3629 settled that a Session has one revisioned SandboxPolicy and that Runtime evaluates ordinary tool calls before first dispatch. One execution path still sits outside that picture, and I'd like to check whether it belongs inside it.

Observation

McpManager.openClient (packages/mcp/src/index.ts:1115) constructs StdioClientTransport directly, and nothing under packages/mcp/src references the sandbox. So in a Session where Bash is confined by Seatbelt or bwrap — and fails closed when no backend is available — a stdio MCP server named in the same config runs as an ordinary child of Runtime Host: full user identity, full filesystem, full network. Its tools are then offered to the model.

Two things are better than that summary suggests and should stay as they are:

• the stdio environment is an allowlist, not an exclusion list (buildStdioEnvironment, index.ts:2409);
• MCP tool calls under a managed boundary already require network approval (packages/runtime/src/mcp-tools.ts:147-157).

Neither confines the process. The call is gated; the thing that could do anything is not.

Why the existing threads don't cover it

• feat: replace per-tool approvals with sandbox boundaries #1564 lists MCP's enforcement owner as "tool exposure plus server or connector scopes", bars MCP from request_sandbox_boundary, says not to introduce a universal capability language for MCP, and — explicitly — says not to claim the local process sandbox contains native or remote tools. So the gap was known and accepted at the time. What feat: replace per-tool approvals with sandbox boundaries #1564 did not decide is whether a Host-spawned server process may be launched under the Session's sandbox backend. That is a launch-time isolation choice for one child process, the same kind filesystem-worker already makes for itself — not a capability language for what the server's tools may do.
• enhancement(runtime): allow Auto mode to use tools currently restricted to Full Access on macOS #4012 is about call-time Session Grants for Desktop-connected MCP, bound to serverId + toolName. It does not touch where a Host-spawned server process runs.

Question

Should sandboxed launch be a per-server declared capability, rather than something inherited from the Session profile? The Session profile is the wrong constraint for many servers — they legitimately need network and out-of-workspace paths — but "no constraint at all" is the current default.

Concretely: route openClient's { command, args, cwd, env } through the existing SandboxManager.transform, the way packages/runtime/src/filesystem-worker/client.ts:444 already does for its own long-lived helper, behind an opt-in per-server flag; and when the platform cannot enforce the declared isolation, fail closed with a typed unsupported-isolation error instead of a bare spawn. That would also give ToolExecutionIsolation (packages/core/src/permission.ts:111) its first non-'none' value in practice.

I'm not attached to the shape — mainly asking whether this is in scope for the post-#3629 SandboxPolicy work, or deliberately out.

中文

#3629 已经确定：一个 Session 有唯一的带 revision 的 SandboxPolicy，Runtime 在工具首次执行前完成判断。但有一条执行路径目前在这个图之外。

McpManager.openClient 直接构造 StdioClientTransport，packages/mcp/src 里没有任何地方引用 sandbox。于是在一个 Bash 被 Seatbelt/bwrap 约束、后端不可用时 fail closed 的 Session 里，同一份配置里的 stdio MCP server 却以 Runtime Host 普通子进程的身份运行——完整用户身份、完整文件系统、完整网络。

两处现状是好的、应保留：stdio 环境是白名单；托管边界下的 MCP 工具调用已经需要网络审批。但两者都不约束进程。

#1564 把 MCP 的强制归属定为"工具暴露 + server/connector 自身的 scope"，禁止 MCP 使用 request_sandbox_boundary，明确不为 MCP 引入通用能力语言，并且明说"不要声称本地进程沙箱覆盖了原生或远程工具"——所以这个缺口当时是已知且接受的。它没有决定的是：Host 自己派生的 server 进程能否在 Session 的沙箱后端下启动。这是对一个子进程的启动期隔离选择（filesystem-worker 已经这么做了），不是描述其工具能做什么的能力语言；#4012 处理的是 Desktop 侧 MCP 的调用时 Session Grant，不涉及 Host 派生的 server 进程跑在哪。

想问的是：沙箱化启动是否应该成为每个 server 自己声明的能力，经现有 SandboxManager.transform 编译（filesystem-worker/client.ts:444 已经这么做了），平台无法强制时以带类型的错误 fail closed，而不是裸 spawn？

主要想确认这是否在 #3629 之后的 SandboxPolicy 工作范围内。

AI assistance disclosure: source verification and drafting assisted by Claude; reviewed by me.