MCP Apps 沙箱代理机制深入Host 如何代理 MCP 请求完整指南【免费下载链接】ext-appsOfficial repo for spec SDK of MCP Apps protocol - standard for UIs embedded AI chatbots, served by MCP servers项目地址: https://gitcode.com/GitHub_Trending/ex/ext-apps在 MCP Apps 协议中工具 UI 运行在 AI 聊天机器人Host嵌入的沙箱 iframe 里而真正的 MCP 服务器在浏览器之外。那么 UI 发出的tools/call等 MCP 请求是如何到达服务器的答案就是MCP Apps 的 Host 沙箱代理机制Host 通过AppBridge充当中间人把沙箱内的 MCP 请求原样代理转发给 MCP 服务器再把结果送回。一图看懂 MCP Apps 的三层架构MCP Apps 让 MCP 服务器提供可交互的 UI图表、表单、仪表盘直接渲染在聊天客户端中。整条链路如下Viewiframe 内 UI ↔ AppBridge ↔ Host ↔ MCP ServerView不可信的第三方 UI 代码跑在沙箱里不能直连服务器AppBridgeHost 侧的桥接层SDK 中的 app-bridge.ts负责双向转发Host聊天客户端如 Claude持有唯一一条到 MCP 服务器的连接 为什么不让 UI 直连服务器因为 UI 代码来自任意的 MCP 服务器必须隔离同时 Host 是唯一有权访问服务器凭据、用户会话的一方。双层 iframe 沙箱代理的外层围栏MCP Apps 规定Host 与沙箱必须使用不同的源origin。参考实现 basic-host 用了巧妙的双层结构Host (端口 8080) └── 外层 iframe (端口 8081) —— 沙箱代理 └── 内层 iframe (srcdoc) —— 不可信的工具 UI外层 iframe 运行在独立源上即使被攻破也无法直接触碰 Host 的 DOM、Cookie 和 JS 上下文内层 iframe 接收 HTML并受sandbox属性如allow-scripts、allow-forms限制所有消息经外层 iframe验证后双向中继Host ↔ Sandbox ↔ View核心逻辑在 examples/basic-host/src/sandbox.ts收到父窗口消息时先校验 origin 是否为预期的 Host 源转发到内层 iframe 时也使用指定 origin 而非*防止消息被拦截。 想亲眼看到每一次请求的转发过程仓库里的 debug-server 示例会实时打印 View 与服务器之间的全部消息。核心机制AppBridge 自动转发 MCP 请求这是Host 如何代理 MCP 请求的关键一步。在 SDK 的 AppBridge.connect() 中当构造时传入了 MCP client它会根据服务器声明的能力自动注册代理处理器服务器能力自动代理的方法toolstools/callnotifications/tools/list_changedresourcesresources/list、resources/read、resources/templates/list 列表变更通知promptsprompts/list 列表变更通知工作流程非常直白View 在 iframe 里发出tools/call请求请求经 PostMessage 到达 Host 的 AppBridgeAppBridge 把它原样转发给 MCP client即 MCP 服务器服务器返回结果后再经由同一条通道送回 View如果没有传入 clientHost 也可以手动接管——通过 oncalltool、onreadresource 等钩子自定义处理逻辑从而实现审计、限流或人工确认human-in-the-loop。Host 侧的完整接线过程可参考 examples/basic-host/src/implementation.ts创建AppBridge、传入hostContext主题、容器尺寸、显示模式connect()后即进入初始化握手随后用sendToolInput/sendToolResult把工具调用的输入与结果推送给沙箱内的 UI。消息通道上的 4 道安全关卡 代理之所以可信靠的是层层校验见 sandbox.ts 与 docs/csp-cors.mdReferrer 白名单外层沙箱加载时验证嵌入方必须是允许的源否则直接抛错沙箱自测尝试访问window.top预期必须触发 SecurityError证明隔离生效双向 origin 校验Host 与 View 的消息都带 origin 白名单不匹配即丢弃HTTP 头注入 CSPCSP 由 Host 以响应头形式下发而非 meta 标签不可被 UI 自身篡改_meta.ui.csp声明的connectDomains/resourceDomains决定了 UI 允许访问哪些网络端点本地 3 步跑通沙箱代理无需任何复杂环境basic-host 就是一个现成的实验场进入 examples/basic-host执行npm install npm run start浏览器打开http://localhost:8080默认连接http://localhost:3001/mcp的服务器选一个工具、填参数调用观察 UI 如何从服务器取 HTML、在沙箱中渲染并代理后续的 MCP 请求 延伸阅读规范文档 specification/2026-01-26/apps.mdx、CSP 与 CORS 配置指南、SDK 使用示例。理解了这套双层沙箱 AppBridge 代理的组合你就掌握了 MCP Apps 安全模型的全部精髓UI 永远被隔离Host 永远是唯一的代理与裁判。【免费下载链接】ext-appsOfficial repo for spec SDK of MCP Apps protocol - standard for UIs embedded AI chatbots, served by MCP servers项目地址: https://gitcode.com/GitHub_Trending/ex/ext-apps创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MCP Apps 沙箱代理机制深入：Host 如何代理 MCP 请求（完整指南）
MCP Apps 沙箱代理机制深入Host 如何代理 MCP 请求完整指南【免费下载链接】ext-appsOfficial repo for spec SDK of MCP Apps protocol - standard for UIs embedded AI chatbots, served by MCP servers项目地址: https://gitcode.com/GitHub_Trending/ex/ext-apps在 MCP Apps 协议中工具 UI 运行在 AI 聊天机器人Host嵌入的沙箱 iframe 里而真正的 MCP 服务器在浏览器之外。那么 UI 发出的tools/call等 MCP 请求是如何到达服务器的答案就是MCP Apps 的 Host 沙箱代理机制Host 通过AppBridge充当中间人把沙箱内的 MCP 请求原样代理转发给 MCP 服务器再把结果送回。一图看懂 MCP Apps 的三层架构MCP Apps 让 MCP 服务器提供可交互的 UI图表、表单、仪表盘直接渲染在聊天客户端中。整条链路如下Viewiframe 内 UI ↔ AppBridge ↔ Host ↔ MCP ServerView不可信的第三方 UI 代码跑在沙箱里不能直连服务器AppBridgeHost 侧的桥接层SDK 中的 app-bridge.ts负责双向转发Host聊天客户端如 Claude持有唯一一条到 MCP 服务器的连接 为什么不让 UI 直连服务器因为 UI 代码来自任意的 MCP 服务器必须隔离同时 Host 是唯一有权访问服务器凭据、用户会话的一方。双层 iframe 沙箱代理的外层围栏MCP Apps 规定Host 与沙箱必须使用不同的源origin。参考实现 basic-host 用了巧妙的双层结构Host (端口 8080) └── 外层 iframe (端口 8081) —— 沙箱代理 └── 内层 iframe (srcdoc) —— 不可信的工具 UI外层 iframe 运行在独立源上即使被攻破也无法直接触碰 Host 的 DOM、Cookie 和 JS 上下文内层 iframe 接收 HTML并受sandbox属性如allow-scripts、allow-forms限制所有消息经外层 iframe验证后双向中继Host ↔ Sandbox ↔ View核心逻辑在 examples/basic-host/src/sandbox.ts收到父窗口消息时先校验 origin 是否为预期的 Host 源转发到内层 iframe 时也使用指定 origin 而非*防止消息被拦截。 想亲眼看到每一次请求的转发过程仓库里的 debug-server 示例会实时打印 View 与服务器之间的全部消息。核心机制AppBridge 自动转发 MCP 请求这是Host 如何代理 MCP 请求的关键一步。在 SDK 的 AppBridge.connect() 中当构造时传入了 MCP client它会根据服务器声明的能力自动注册代理处理器服务器能力自动代理的方法toolstools/callnotifications/tools/list_changedresourcesresources/list、resources/read、resources/templates/list 列表变更通知promptsprompts/list 列表变更通知工作流程非常直白View 在 iframe 里发出tools/call请求请求经 PostMessage 到达 Host 的 AppBridgeAppBridge 把它原样转发给 MCP client即 MCP 服务器服务器返回结果后再经由同一条通道送回 View如果没有传入 clientHost 也可以手动接管——通过 oncalltool、onreadresource 等钩子自定义处理逻辑从而实现审计、限流或人工确认human-in-the-loop。Host 侧的完整接线过程可参考 examples/basic-host/src/implementation.ts创建AppBridge、传入hostContext主题、容器尺寸、显示模式connect()后即进入初始化握手随后用sendToolInput/sendToolResult把工具调用的输入与结果推送给沙箱内的 UI。消息通道上的 4 道安全关卡 代理之所以可信靠的是层层校验见 sandbox.ts 与 docs/csp-cors.mdReferrer 白名单外层沙箱加载时验证嵌入方必须是允许的源否则直接抛错沙箱自测尝试访问window.top预期必须触发 SecurityError证明隔离生效双向 origin 校验Host 与 View 的消息都带 origin 白名单不匹配即丢弃HTTP 头注入 CSPCSP 由 Host 以响应头形式下发而非 meta 标签不可被 UI 自身篡改_meta.ui.csp声明的connectDomains/resourceDomains决定了 UI 允许访问哪些网络端点本地 3 步跑通沙箱代理无需任何复杂环境basic-host 就是一个现成的实验场进入 examples/basic-host执行npm install npm run start浏览器打开http://localhost:8080默认连接http://localhost:3001/mcp的服务器选一个工具、填参数调用观察 UI 如何从服务器取 HTML、在沙箱中渲染并代理后续的 MCP 请求 延伸阅读规范文档 specification/2026-01-26/apps.mdx、CSP 与 CORS 配置指南、SDK 使用示例。理解了这套双层沙箱 AppBridge 代理的组合你就掌握了 MCP Apps 安全模型的全部精髓UI 永远被隔离Host 永远是唯一的代理与裁判。【免费下载链接】ext-appsOfficial repo for spec SDK of MCP Apps protocol - standard for UIs embedded AI chatbots, served by MCP servers项目地址: https://gitcode.com/GitHub_Trending/ex/ext-apps创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考