关于 Open Computer Use
Open Computer Use 是一个 MCP 服务,为任意 LLM 提供基于 Docker 沙箱的独立计算环境,包含终端、浏览器、文档技能和子 Agent。它可自托管,适合多用户部署,但项目已归档,不再维护。
主要功能
- 01每个会话独立的 Docker 容器
- 02实时 CDP 浏览器画面与交互
- 03内置 13 项技能,涵盖文档与网页测试
- 04可调用 Claude Code、Codex 或 OpenCode 的子 Agent
- 05通过 Streamable HTTP 接入 MCP 客户端
适用场景
- 01在聊天界面中为模型提供代码执行与文档生成环境
- 02用 Playwright 技能进行网页测试与抓取
- 03在自托管环境中试验 LLM 的计算机使用能力
MCP 相关
该服务通过 Streamable HTTP 的 /mcp 端点对外提供沙箱能力,供 Open WebUI、Claude Desktop、n8n 等 MCP 客户端调用。
配置
本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。
我们还没有获取到这个服务的安装包或远程地址,请按项目 README 中的说明安装。
工具
本地服务需要在你的电脑上运行后才能读取工具,维护者暂未提供工具列表。
详细介绍
开放式计算机使用
为任意大模型提供专属计算机的 MCP 服务——采用受管理的 Docker 工作空间,配备实时浏览器、终端、代码执行、文档技能和自主子 Agent。可自托管、开源,并可接入任意模型。
已归档。 此代码库不再开发或维护,不会收到修复、安全更新或依赖项更新,问题和拉取请求也已关闭。请勿在生产环境中运行。
Open Computer Use 是一项概念验证,旨在为大模型提供一台真正的计算机。其继任项目是 Wide Moat:Open WebUI 搭配 Open Terminal、浏览器,以及通过 gVisor 隔离的 Kubernetes 沙箱,并配备入口 sidecar 和通过 MITM 代理的出口流量。已知限制中列出的隔离和凭据处理问题,在该架构中得到了解决,而非在此代码库中。欢迎在 ai.lab.widemoat.ai 体验。
代码继续以 FSL-1.1-Apache-2.0 许可证提供:可使用、分叉并自行托管。每个版本发布两年后都会转为 Apache-2.0 许可证。

这是什么?
一个 MCP 服务,为任意大模型提供配备齐全的 Ubuntu 沙箱,并使用相互隔离的 Docker 容器。可以把它看作 AI 的计算机——它能完成开发者能做的一切:
- 执行代码——在隔离容器中运行 bash、Python、Node.js、Java
- 创建文档——借助技能,以专业样式创建 Word、Excel、PowerPoint 和 PDF 文档
- 浏览网页——Playwright + 实时 CDP 浏览器串流(你可以实时看到 AI 所见)
- 运行 Claude Code——配备交互式终端的自主子 Agent,自动配置 MCP 服务
- 使用 13+ 项技能——经过实战验证的工作流,适用于文档创建、网页测试、设计等
专为生产级多用户部署打造。 已通过 1,000+ MAU 测试。每个聊天会话都在独立的 Docker 容器中运行——AI 可以安装软件包、创建文件、运行服务,用户之间互不影响。可在各种 MCP 客户端之间无缝切换:今天使用 Open WebUI,明天切换到 Claude Desktop 或 n8n——后端不变,无需迁移。
核心差异
| 功能 | Open Computer Use | Claude.ai(Claude Code web) | open-terminal | OpenAI Operator |
|---|---|---|---|---|
| 可自托管 | 是 | 否 | 是 | 否 |
| 支持任意大模型 | 是(兼容 OpenAI) | 仅 Claude | 任意模型(通过 Open WebUI) | 仅 GPT |
| 代码执行 | 完整的 Linux 沙箱 | 沙箱(Claude Code web) | 沙箱 / 裸机 | 否 |
| 实时浏览器 | CDP 流式传输(共享、可交互) | 基于截图 | 否 | 基于截图 |
| 终端 + Claude Code | ttyd + tmux + Claude Code CLI | Claude Code web(内置) | PTY + WebSocket | 不适用 |
| 技能系统 | 13 个内置技能(自动注入)+ 自定义技能 | 内置技能 + 自定义指令 | Open WebUI 原生(仅文本) | 不适用 |
| 容器隔离 | Docker(runc),每个聊天独立 | Docker(gVisor) | 共享容器(操作系统级用户) | 不适用 |
可与任何兼容 MCP 的客户端配合使用:Open WebUI、Claude Desktop、LiteLLM、n8n 或你自己的集成。请参阅 docs/COMPARISON.md,了解与其他方案的详细比较。
实时浏览器流式传输

使用技能预览文件

前端设计 — 在浏览器标签页中实时呈现的落地页

演示文稿 — 定制设计系统,而非默认的白色模板

创建自己的技能 — 将重复性工作封装为可复用函数

数据 → 图表与分析

Claude Code — 云端交互式终端

子 Agent 控制面板 — 监控与控制

请参阅 docs/FEATURES.md 了解架构详情,并参阅 docs/SCREENSHOTS.md 查看所有截图。
实用建议:在终端中使用 Claude Code 创建技能,然后在聊天中搭配任意模型使用。技能与模型无关——编写一次,随处使用。
多 CLI 子 Agent 运行时(v0.9.2.1+):子 Agent 调度支持 Claude Code(默认)、OpenAI Codex 和 OpenCode(支持 OpenRouter / qwen / DeepSeek / 75+ 个提供商)。在
.env中切换SUBAGENT_CLI=claude|codex|opencode——请参阅 docs/multi-cli.md,了解 OpenCode + qwen3-coder + OpenRouter 的完整配置示例。
架构
docs/future-architecture/ 中包含有关 Kubernetes 架构的设计说明,该架构未在此仓库中构建。本项目代码仅支持 Docker Compose。
试用方式
| 方式 | URL | 所需条件 | 适用场景 |
|---|---|---|---|
| 免费在线演示 — Open WebUI + Computer Use,已包含模型 | ai.lab.widemoat.ai | 使用 GitHub 或 Google 登录 | 30 秒内端到端体验 |
| 自托管 | 下方的 快速入门 | Docker,首次构建约需 15 分钟 | 完全掌控、隔离网络环境、高强度使用 |
仅支持 OAuth 登录——不支持邮箱/密码或短信登录。在 ai.lab.widemoat.ai 上,模型作为免费便利服务提供。托管的 MCP 端点目前不可用;请参阅 docs/CLOUD.md。
快速开始
git clone https://github.com/Wide-Moat/open-computer-use.git
cd open-computer-use
cp .env.example .env
# Edit .env — set OPENAI_API_KEY (or any OpenAI-compatible provider)
# 1. Start Computer Use Server (builds workspace image on first run, ~15 min)
docker compose up --build
# 2. Start Open WebUI (in another terminal)
docker compose -f docker-compose.webui.yml up --build
打开 http://localhost:3000,即可使用已配置好 Computer Use 的 Open WebUI。
注意: 使用两个独立的 docker-compose 文件:
docker-compose.yml(Computer Use Server)和docker-compose.webui.yml(Open WebUI)。它们通过localhost:8081通信。这模拟了实际部署场景:服务和 UI 运行在不同的主机上。
模型设置(重要!)
在 Open WebUI 中添加模型后,前往 Model Settings 并设置:
| 设置 | 值 | 原因 |
|---|---|---|
| Function Calling | Native | Computer Use 工具正常工作所必需 |
| Stream Chat Response | On | 启用实时输出流 |
如果没有设置 Function Calling: Native,模型就不会调用 Computer Use 工具。
沙箱包含的内容
| 类别 | 工具 |
|---|---|
| 语言 | Python 3.12、Node.js 22、Java 21、Bun |
| 文档 | LibreOffice、Pandoc、python-docx、python-pptx、openpyxl |
| pypdf、pdf-lib、reportlab、tabula-py、ghostscript | |
| 图像 | Pillow、OpenCV、ImageMagick、sharp、librsvg |
| Web | Playwright(Chromium)、Mermaid CLI |
| AI | Claude Code CLI、Playwright MCP |
| OCR | Tesseract(可配置语言) |
| 媒体 | FFmpeg |
| 图表 | Graphviz、Mermaid |
| 开发 | TypeScript、tsx、git |
技能
13 个内置公开技能 + 14 个示例:
| 技能 | 描述 |
|---|---|
| pptx | 使用 html2pptx 创建/编辑 PowerPoint 演示文稿 |
| docx | 创建/编辑带修订记录的 Word 文档 |
| xlsx | 使用公式创建/编辑 Excel 电子表格 |
| 创建、填写表单、提取内容、合并 PDF | |
| sub-agent | 将复杂任务委派给 Claude Code |
| playwright-cli | 浏览器自动化和网页抓取 |
| describe-image | 使用视觉 API 分析图像 |
| frontend-design | 构建可用于生产环境的 UI |
| webapp-testing | 使用 Playwright 测试 Web 应用 |
| doc-coauthoring | 结构化文档协作工作流 |
| test-driven-development | 强制执行 TDD 方法 |
| skill-creator | 创建自定义技能 |
| gitlab-explorer | 探索 GitLab 仓库 |
14 个示例技能:web-artifacts-builder、copy-editing、social-content、canvas-design、algorithmic-art、theme-factory、mcp-builder 等。
详情请参阅 docs/SKILLS.md。
MCP 集成
该服务使用标准的 Streamable HTTP 协议进行 MCP 通信。将任意 MCP 客户端指向你自己的部署即可。
- 自托管:
http://localhost:8081/mcp。快速检查:
完整的自托管集成指南(LiteLLM、Claude Desktop、自定义客户端):docs/MCP.md。每个聊天的系统提示词通过 六种冗余的 MCP 原生渠道传递(工具描述、沙箱中的curl -X POST http://localhost:8081/mcp \ -H "Content-Type: application/json" \ -H "X-Chat-Id: test" \ -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'/home/assistant/README.md、InitializeResult.instructions、用于已上传文件的resources/list,以及供旧版集成使用的 HTTP/system-prompt端点);完整说明见 docs/system-prompt.md。
配置
所有设置均通过 .env 配置:
| 变量 | 默认值 | 说明 |
|---|---|---|
OPENAI_API_KEY | — | 大模型 API 密钥(兼容任何 OpenAI 的服务) |
OPENAI_API_BASE_URL | — | 自定义 API 基础 URL(OpenRouter 等) |
MCP_API_KEY | — | MCP 端点的 Bearer 令牌 |
DOCKER_IMAGE | open-computer-use:latest | 沙箱容器镜像 |
COMMAND_TIMEOUT | 120 | Bash 工具超时时间(秒) |
SUB_AGENT_TIMEOUT | 3600 | 子 Agent 超时时间(秒) |
SINGLE_USER_MODE | — | true = 使用单个容器,无需聊天 ID;false = 要求提供 X-Chat-Id;未设置 = 宽松模式 |
PUBLIC_BASE_URL | http://computer-use-server:8081 | 浏览器可访问的 Computer Use 服务 URL。该值会写入 /system-prompt,并通过 X-Public-Base-URL 响应标头返回给 Open WebUI 过滤器——作为公共 URL 的唯一真实来源。Open WebUI 过滤器 URL 要求。 |
CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS、ORCHESTRATOR_URL、TOOL_RESULT_MAX_CHARS、TOOL_RESULT_PREVIEW_CHARS | — | open-webui 容器(而非 CU-server)中的设置。嵌入时必须配置——请参阅将 Open WebUI 嵌入自有堆栈时的必要设置。 |
POSTGRES_PASSWORD | openwebui | PostgreSQL 密码 |
VISION_API_KEY | — | 视觉 API 密钥(用于 describe-image) |
ANTHROPIC_AUTH_TOKEN | — | Anthropic 密钥(用于 Claude Code 子 Agent) |
MCP_TOKENS_URL | — | Settings Wrapper URL(可选,见下文) |
MCP_TOKENS_API_KEY | — | Settings Wrapper 身份验证密钥 |
自定义技能与令牌管理(可选)
默认情况下,所有 13 项内置技能均对所有人开放。若要按用户设置技能访问权限并添加自定义技能,请部署 Settings Wrapper——请参阅 settings-wrapper/README.md。
个人访问令牌(PAT): Settings Wrapper 还可以为外部服务(GitLab、Confluence、Jira 等)存储按用户加密的 PAT。服务端会根据用户邮箱获取这些令牌,并注入沙箱——因此每位用户的 AI 都可以访问自己的代码库和文档,而无需共享凭据。服务端的令牌注入代码已实现(docker_manager.py),但 Open WebUI 工具不会传递所需的标头,也不会对此进行修改。
MCP 客户端集成
Computer Use Server 使用标准的 MCP over Streamable HTTP 协议——任何兼容 MCP 的客户端都可以连接。Open WebUI 是主要经过测试的前端,但并非唯一选择。
| 客户端 | 可自托管的 URL | 状态 |
|---|---|---|
| Open WebUI | 已包含 Docker Compose 堆栈,并自动配置 | 已在生产环境中测试 |
| Claude Desktop | http://localhost:8081/mcp——请参阅 docs/MCP.md | 可用 |
| n8n | MCP Tool 节点 → http://computer-use-server:8081/mcp | 可用 |
| LiteLLM | MCP 代理配置——请参阅 docs/MCP.md | 可用 |
| 自定义客户端 | 任何支持 MCP JSON-RPC 的 HTTP 客户端——请参阅 docs/MCP.md 中的 curl 示例 | 可用 |
Open WebUI 集成
Open WebUI 是一个可扩展、可自托管的 AI 界面。我们将其用作主要前端,因为它支持工具调用、函数过滤器和 artifacts——这些都是 Computer Use 所需的功能。
**兼容性:**此构建版本专门针对 Open WebUI 0.11.0 构建并经过验证。我们构建版本号的前 3 段(v0.11.0.X)始终与其适用的 Open WebUI 基础版本一致。如果你运行的是其他 Open WebUI 版本,请选择前 3 段版本号与你的版本一致的 Open Computer Use 构建版本——例如,Open WebUI 0.8.12 对应 v0.8.12.Y 构建版本。
**为什么不使用分支?**Computer Use 本身不是分支:它通过官方插件 API(工具和函数)接入,因此安装工具和过滤器后,原版 Open WebUI 即可正常运行。(确实存在一个单独的分支,用于实现无法通过插件表达的改动,但此仓库不依赖它。)
通过企业网关(LiteLLM、Azure、Bedrock)运行 Claude Code?请参阅 docs/claude-code-gateway.md,了解三种路径的运维方案。
openwebui/ 目录包含:
- tools/ — MCP 客户端工具(Computer Use Server 的轻量代理)。必需——这是 Open WebUI 与沙盒之间的桥梁。
- functions/ — 系统提示词注入器 + 文件链接重写器 + 归档按钮。必需——没有它,模型就无法识别技能和文件 URL。
- patches/ — 用于 artifacts、错误处理和文件预览的构建时修复。可选,但建议启用——可显著改善用户体验。
- init.sh — 首次启动时自动安装工具和过滤器。可选——你也可以通过 Workspace UI 手动安装。
- init.sh — 首次启动时安装工具和过滤器,并设置它们的阀门。
自动初始化的工作原理
首次运行 docker compose up 时,初始化脚本会自动:
- 创建一个管理员用户(
[email protected]/admin) - 通过
POST /api/v1/tools/create安装 Computer Use 工具 - 通过
POST /api/v1/functions/create安装 Computer Use 过滤器 - 配置工具和过滤器的阀门(
ORCHESTRATOR_URL=http://computer-use-server:8081— 用于服务端到服务端通信的内部 URL,并写入两者的 Valves) - 将工具设为公开可读(为
group:*和user:*通配符授予访问权限),这样非管理员用户也能在工作区中看到该工具 - 将过滤器设为已启用且全局生效(两个单独的开关:
/toggle和/toggle/global)——仅启用而未设为全局生效的过滤器不会生效,这是手动设置时常见的错误 - 通过
POST /api/v1/configs/models将{function_calling: "native", stream_response: true}合并到DEFAULT_MODEL_PARAMS中——这样所有模型都会获得正确的默认值,无需逐个点击模型的 Advanced Params
标记文件(.computer-use-initialized)可防止后续启动时重复运行初始化脚本。
**注意:**Open WebUI 不支持从文件系统预安装工具——必须通过 REST API 加载。初始化脚本会自动完成此操作,无需手动处理。
手动设置(如果不使用 docker-compose)
如果单独运行 Open WebUI,则需要手动执行以下操作:
- 前往 Workspace > Tools → 创建新工具 → 粘贴
openwebui/tools/computer_use_tools.py的内容 - 将 Tool ID 设置为
ai_computer_use(过滤器正常工作所必需) - 配置 Valves:将
ORCHESTRATOR_URL设为 Computer Use Server 的内部 URL(Docker compose 下为http://computer-use-server:8081) - 打开工具的 ⋯ → Share 菜单,并将访问权限设为 Public(授予
group:*和user:*通配符读取权限)——否则只有管理员账户能看到该工具,非管理员用户会看到空工具列表,且不会收到任何错误提示 - 前往 Workspace > Functions → 创建新函数 → 粘贴
openwebui/functions/computer_link_filter.py - 启用过滤器:在 Functions 列表中同时切换 Active 和 Global——这是两个独立的开关;如果只启用 Active 而未启用 Global,过滤器会加载,但不会应用于聊天
- 在模型设置中,将 Function Calling 设为
Native,并将 Stream Chat Response 设为On。也可以在 Admin → Settings → Models → Advanced Params 中一次性设置全局参数(function_calling: native、stream_response: true)——这会成为所有模型的DEFAULT_MODEL_PARAMS。
docker-compose 堆栈会自动处理以上所有事项。
将 Open WebUI 嵌入自己的堆栈时的必要设置
如果在官方 docker-compose.webui.yml 之外运行 Open WebUI——例如使用自己的 compose、Kubernetes、Portainer 或下游仓库——有 四个陷阱会悄无声息地导致 Computer Use 无法工作。这四个问题都曾在我们的生产环境中出现。请按以下顺序检查。
第 1 步 — 本仓库只需要官方上游镜像
安装工具和过滤器后,Computer Use 即可在已发布的
ghcr.io/open-webui/open-webui 上正常工作,无需重新构建任何内容。
过去的情况恰恰相反:仓库中包含八个补丁脚本和一个 Dockerfile,用于将补丁应用到已构建的镜像上;拉取上游镜像时会悄无声息地跳过所有补丁。这些补丁现已移除。它们解决的问题中,有三个已在上游修复;其余问题则以源代码提交的形式存在于一个分叉仓库中,这与运行此集成是两回事。
预览 URL 检测也无需在构建时配置主机——iframe 来源会从模型写入的 URL 中读取,该 URL 来自服务端的 PUBLIC_BASE_URL。
第 3 步 — 两个 URL 设置,两种用途(公开与内部)
v4.0.0: 旧版“必须保持一致的三个 FILE_SERVER_URL 设置位置”这个易错点已消失。现在只有两个位置,分别对应两种不同用途——公开(浏览器可访问)与内部(Docker 本地)。COMPUTER_USE_SERVER_URL 构建参数已在 v0.9.2.0 中移除——fix_preview_url_detection 现在与主机无关(见第 2 步)。
| 位置 | 用途 | 读取方 | 生产环境(配置域名) | 本地开发(Docker Desktop) |
|---|---|---|---|---|
computer-use-server 容器上的 PUBLIC_BASE_URL 环境变量(docker-compose.yml / .env) | 公开——写入 /system-prompt 链接,并通过 X-Public-Base-URL 响应头返回给过滤器 | 服务端(公开 URL 的唯一真实来源) | https://cu.your-domain.com | http://localhost:8081 |
过滤器和工具的阀门 ORCHESTRATOR_URL(由 init.sh 从 open-webui 容器上的 ORCHESTRATOR_URL 环境变量填充) | 内部——服务端之间获取 /system-prompt;转发 MCP tools/call | 过滤器和工具(Docker 网络) | http://computer-use-server:8081 | http://computer-use-server:8081 |
⚠️ 不要将 ORCHESTRATOR_URL 指向你的公开域名。 虽然技术上可行,但这样每个 MCP 请求都会经过浏览器→CDN→Traefik→容器。链路中的任何故障都会导致流在工具调用过程中中断,用户会看到 MCP call failed: Session terminated。请留在 Docker 网络内。
过滤器已不再提供公开 URL 阀门——它会从服务端的 X-Public-Base-URL 响应头读取公开 URL,并将其与提示词一并缓存。一个公开设置,一个内部设置。
另请参阅 docs/openwebui-filter.md。
第 4 步 — open-webui 容器上的四个环境变量
将以下内容复制粘贴到下游 compose 的 environment: 区块中:
services:
open-webui:
environment:
# --- Computer Use required env vars (read by build-time patches) ---
- CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS=200
- TOOL_RESULT_MAX_CHARS=50000
- TOOL_RESULT_PREVIEW_CHARS=2000
# Internal URL of the Computer Use server — seeded by init.sh into both
# Tool and Filter Valves, and read by the fix_large_tool_results patch.
# Same Docker network: use the service DNS name.
- ORCHESTRATOR_URL=http://computer-use-server:8081
| 变量 | 未设置时的默认值 | 正确设置后的效果 |
|---|---|---|
CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS | 256(上游) | 每轮的工具调用上限;原始仓库设为 200,-1 表示禁用上限。Open WebUI 会将旧版(0.10 之前)的名称 CHAT_RESPONSE_MAX_TOOL_CALL_RETRIES 作为备用值读取。 |
TOOL_RESULT_MAX_CHARS | 50000(补丁内置) | 工具结果超过此截断阈值时,会被截断或上传。0 表示禁用。 |
TOOL_RESULT_PREVIEW_CHARS | 2000(补丁内置) | 截断或上传后,模型可见的预览大小。 |
ORCHESTRATOR_URL | 空 | 由 init.sh 填入工具和过滤器的阀门,并由 fix_large_tool_results 补丁读取,作为上传目标。如果为空,超大结果会被静默截断——模型会丢失这些数据。 |
注意:如果使用的是上游 ghcr.io 镜像,最后三个变量不起作用——它们需要第 1 步中的
fix_large_tool_results。
步骤 5 — 筛选器必须设为全局,工具必须允许公开读取
Open WebUI 为每个函数提供了两个独立开关(is_active 和 is_global),为每个工具提供了两项必需授权(group:* + user:*)。自带的 init.sh 会为你完成这些设置;手动部署或自定义部署通常会漏掉其中一项,然后花上好几个小时纳闷“明明都装好了,为什么什么都不能用”。
| 资源 | 要切换的设置 | UI 路径 | 端点 | 原因 |
|---|---|---|---|---|
筛选器 computer_use_filter | is_active = true 且 is_global = true | Admin → Functions → computer_use_filter → 切换 Active + 切换 Global | POST /api/v1/functions/id/computer_use_filter/toggle + .../toggle/global | is_active 只会加载函数;is_global 才会将其应用到每个聊天会话。已启用但非全局时会静默失效,且不会留下任何日志。 |
工具 ai_computer_use | 授予 group:* 和 user:* 的访问权限,permission: read | Workspace → Tools → ai_computer_use → ⋯ → Share → Public | POST /api/v1/tools/id/ai_computer_use/access/update,参数为 {"access_grants":[{"principal_type":"group","principal_id":"*","permission":"read"},{"principal_type":"user","principal_id":"*","permission":"read"}]} | 没有授权时,只有创建该工具的管理员账号能看到它。非管理员用户会看到空工具列表,且不会收到错误提示。UI 中的“Public”开关会写入两个通配授权;只写入其中一个,会导致部分用户能看到工具、其他用户看不到,具体取决于 Open WebUI 版本。 |
对照数据库进行验证(自带堆栈使用 Postgres;参见 docker-compose.webui.yml:53):
# Filter flags — expect (t, t):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
"SELECT is_active, is_global FROM function WHERE id='computer_use_filter';"
# Tool grants — expect TWO rows (group|* and user|*, both 'read'):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
"SELECT principal_type, principal_id, permission FROM access_grant WHERE resource_id='ai_computer_use';"
对于使用 SQLite 的 Open WebUI 部署,将 psql 替换为 sqlite3 /app/backend/data/webui.db,并使用相同的 SQL。
步骤 6 — 一次性验证所有内容
# 1. Env vars reached the container:
docker exec open-webui env | grep -E 'CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS|TOOL_RESULT_|ORCHESTRATOR_URL'
# 4. Tool+Filter Valve (Session-terminated trap) — Admin UI is simplest:
# Workspace → Tools → ai_computer_use → Valves → ORCHESTRATOR_URL
# Admin → Functions → computer_link_filter → Valves → ORCHESTRATOR_URL
# → both must be http://computer-use-server:8081 (internal URL, Docker service DNS),
# NOT your public domain.
# 5. Server env (baked into system prompt AND returned to filter via header):
docker exec computer-use-server env | grep ^PUBLIC_BASE_URL=
# → must be a URL your browser can reach (e.g. http://localhost:8081 for local dev).
# 7. Filter is ACTIVE *and* GLOBAL (see Step 5):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
"SELECT is_active, is_global FROM function WHERE id='computer_use_filter';"
# → expect (t, t). Two 't's, not one.
# 8. Tool is public-read with both wildcards (see Step 5):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
"SELECT principal_type, principal_id, permission FROM access_grant WHERE resource_id='ai_computer_use';"
# → expect TWO rows: (group, *, read) and (user, *, read).
重新构建镜像后,在浏览器中执行一次强制重新加载(Cmd+Shift+R / Ctrl+Shift+R)。否则浏览器会保留旧的缓存 JS 代码块,让你误以为修复没有生效。
症状 → 出错步骤
| 症状 | 步骤 |
|---|---|
HTML 成品在聊天中显示为原始 <iframe ...> 文本 | 1(上游镜像缺少 fix_artifacts_auto_show) |
| 文件链接未自动插入预览 iframe | 1(缺少 fix_preview_url_detection),或浏览器无法访问 PUBLIC_BASE_URL |
每次调用工具都出现 MCP call failed: Session terminated | 3(工具 Valve 指向公共域名) |
| 工具循环提前中断;显示 “Model temporarily unavailable” 横幅 | 4(未设置 CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS) |
大型工具输出静默显示为 ...(truncated);模型因此做出错误判断 | 4(未设置 ORCHESTRATOR_URL 或无法访问),或 1(缺少 fix_large_tool_results) |
| 工具循环错误显示原始 Python 异常 | 1(缺少 fix_tool_loop_errors) |
| 非管理员用户的工具列表为空(管理员可以看到) | 5(工具缺少 access_grant——未设为公开读取) |
| 筛选器在 UI 中显示为“Active”,但预览 iframe / 归档按钮始终未出现 | 5(筛选器 is_global=false——只切换了 is_active=true) |
| 聊天中的文件链接跳转到 404 / 白屏 | 服务器上的 PUBLIC_BASE_URL 与浏览器实际可访问的地址不一致——参见 docs/openwebui-filter.md |
| 重新构建后仍未看到新行为 | 浏览器缓存了旧 JS——执行强制重新加载 |
安全说明
在可自托管环境中的 Open WebUI 上,已使用 1000+ 用户进行生产环境测试。该项目已不再维护;未修复的问题列于下方。
当前模型
- Docker socket:服务器需要访问 Docker socket 才能管理沙盒容器。这会授予对主机的重大访问权限——仅在可信环境中运行。
- MCP_API_KEY:在生产环境中设置一个强随机密钥。若未设置,任何能访问网络端口 8081 的人都可以在容器中执行任意命令。
- 沙盒隔离:每个聊天会话都在单独的容器中运行,并设有资源限制(2GB RAM、1 CPU)。在 Docker Compose 中,容器使用标准运行时(runc),并共享主机内核。Kubernetes Helm chart 默认使用无 root 权限的 Podman——用户命名空间加 AppArmor,且不使用特权容器;也可以选择使用 Kata Containers,以获得虚拟机监控程序级别的隔离边界。在 Compose 中,gVisor 从未接入。容器默认可访问网络。
- POSTGRES_PASSWORD:在生产环境中更改
.env中的默认密码。
已知限制
- 未经身份验证的文件/预览端点:
/files/{chat_id}/、/api/outputs/{chat_id}、/browser/{chat_id}/、/terminal/{chat_id}/——知道聊天 ID 的任何人都可以访问。聊天 ID 是 UUID(难以猜测,但不是真正的安全边界)。 - 服务器不提供按用户身份验证:MCP 服务信任任何发送有效
MCP_API_KEY的人。客户端会传递用户身份(X-User-Email),但服务器端不会进行验证。 - HTTP 标头中包含凭据:API 密钥(GitLab、Anthropic、MCP 令牌)会通过 HTTP 标头从客户端传递到服务器。在 Docker 网络内是安全的,但若要对外开放,请使用 HTTPS。
- 默认管理员凭据:
[email protected]/admin——在多用户设置中请立即更改。
尚未修复的安全问题
本仓库不会处理以下问题:
- 按会话签名的令牌,用于文件/预览/终端端点(取代作为身份验证凭据的聊天 ID)
- 通过 Open WebUI JWT 验证进行服务器端用户验证
- 提供自动 TLS 证书的 HTTPS 支持
- 对所有工具调用和文件访问进行审计日志记录
- 为沙盒容器设置网络策略(默认限制出站流量)
- 密钥管理——将凭据从标头移至服务器端加密存储
- gVisor(runsc)运行时——可选的容器沙盒功能,以增强隔离性(类似 Claude.ai)
开发
# Build workspace image locally
docker build --platform linux/amd64 -t open-computer-use:latest .
# Run tests
./tests/test-docker-image.sh open-computer-use:latest
./tests/test-no-corporate.sh
./tests/test-project-structure.sh
# Build and run full stack
docker compose up --build
贡献
本仓库已归档,不接受贡献。请参阅 CONTRIBUTING.md。
社区
- 后续项目:widemoat.ai,演示地址:ai.lab.widemoat.ai
- 联系邮箱:[email protected]
许可证
本项目采用多许可证模式:
- 核心部分(
computer-use-server/、openwebui/、settings-wrapper/、Docker 配置):功能源许可证 1.1 版,未来采用 Apache 2.0 许可证(FSL-1.1-Apache-2.0)。可免费使用、修改、分叉、再分发,并在内部自托管。每个版本发布两年后会自动转换为 Apache 2.0。若要提供与我们的付费版本竞争的托管服务或嵌入式服务,则需要签订商业协议。 - 我们的技能(
skills/public/describe-image、skills/public/sub-agent):MIT - 第三方技能:请参阅各自的 LICENSE.txt 文件或原始来源。
必须注明出处:包含“Open Computer Use”以及指向本仓库的链接。
详情请参阅 NOTICE。关于第三方依赖项许可证(PyMuPDF AGPL、Anthropic Skill License、Apache 2.0 bundles 等),请参阅 THIRD-PARTY-LICENSES.md。
评论
一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。