Open Cowork沙箱安全设计揭秘路径守卫与WSL2/Lima虚拟机双层隔离完整指南【免费下载链接】open-coworkOpen-source AI agent desktop app for Windows macOS. One-click install Claude Code, MCP tools, and Skills — with sandbox isolation, multi-model support, and Feishu/Slack integration.项目地址: https://gitcode.com/gh_mirrors/op/open-coworkOpen Cowork是一款面向 Windows 与 macOS 的开源 AI 代理桌面应用它把 Claude Code、MCP 工具与 Skills 打包成一键安装的图形界面而其中最值得称道的设计就是它的沙箱隔离安全体系通过路径守卫 虚拟机双层防护让 AI 执行的所有命令都被关进一个隔离空间即使 AI 生成了危险的删除命令也无法伤到你的宿主系统。本文将从用户视角讲清楚这套安全设计的原理与边界帮你放心地把文件操作交给 AI。为什么 AI 代理需要沙箱隔离AI 代理的强大之处在于它能真正动手读写文件、运行命令、生成文档。但这也是一把双刃剑——如果模型幻觉出一条rm -rf之类的命令直接在你的系统里执行后果不堪设想。Open Cowork 给出的答案是所有 AI 命令都不直接在宿主机上运行。应用启动时会按平台自动选择隔离模式Windows 用 WSL2、macOS 用 Lima 虚拟机、或降级为本地模式这一逻辑集中在 sandbox-adapter.ts 中实现四种模式分别为模式适用平台隔离级别wslWindows完整虚拟机隔离limamacOS完整虚拟机隔离native降级场景仅路径守卫带警告none未启用无沙箱你可以在设置面板中随时查看当前沙箱状态SettingsSandbox.tsx。第一道防线PathGuard 路径守卫路径守卫是沙箱体系的看门人源码位于 path-guard.ts。它的核心思想只有一句话AI 只被允许访问本会话的沙箱工作区其余一切路径默认拒绝。它具体做了四件事1. 系统路径黑名单应用维护了两套平台专属的禁用路径规则WSL/Linux 下封锁/mnt/Windows 文件系统挂载点、/etc/、/usr/、/proc/等系统目录macOS/Lima 下封锁/System/、/Library/、/Applications/、/Volumes/等。AI 一旦试图触碰这些目录会被立即拦截并记录日志。2. 危险命令模式识别PathGuard 内置了一组高危命令特征库包括rm -rf /、chmod 777 /、dd of/dev/...、mkfs格式化、curl | bash远程脚本执行、十六进制混淆序列如$\x等。命中任意一条命令在执行前就被直接拒绝——即使命令最终看起来是安全的。3. 符号链接逃逸检测一个常见攻击手法是在沙箱里放一个指向/etc的软链接让 AI 以为在操作沙箱文件。PathGuard 在处理每个路径时会调用realpath解析出真实位置若真实位置不在沙箱内就判定为符号链接逃逸并拒绝。4. 最小化例外白名单为了让沙箱里能真正干活比如npm installPathGuard 开了极少数的口子/root/.nvm/versions/等 Node.js 运行路径只读放行node_modules仅允许出现在沙箱或系统包路径中。白名单越窄攻击面越小。底层的路径是否位于根目录内判定由 path-containment.ts 提供。它会先把路径规范化统一分隔符、展开.和..、拒绝空字节截断攻击再逐段比较兼容 Windows 盘符、UNC 网络路径和 POSIX 路径三种格式。另一个关键组件 path-resolver.ts 负责虚拟路径 ↔ 真实路径的双向转换AI 看到的永远是/sandbox/workspace/...这样的虚拟地址而真实磁盘位置被严格隐藏在挂载表之后任何越界的解析请求都会返回null而不是猜测。第二道防线WSL2 / Lima 虚拟机隔离路径守卫拦住了文件层面的越界虚拟机则挡住了系统层面的破坏。Windows 端WSL2 完整隔离在 Windows 上Open Cowork 通过 wsl-bridge.ts 与 WSL2 通信。关键机制包括独立 Linux 环境所有命令在 WSL2 的 Linux 发行版内执行一条rm -rf /最多只能毁掉虚拟机里的那个文件系统与你的 C 盘、D 盘无关。路径转换层pathConverter负责D:\project↔/mnt/d/project的双向翻译而沙箱模式下 AI 命令中的 Windows 路径会被 PathGuard 的convertPathInCommand改写成沙箱内路径AI 甚至看不见宿主机目录名。注入防御发行版名、会话 ID 在执行前都经过正则白名单校验只允许字母数字和少量符号防止通过路径字符串注入 shell 命令。macOS 端Lima 轻量虚拟机在 macOS 上lima-bridge.ts 管理一个名为claude-sandbox的 Lima 虚拟机实例通过limactl shell下发命令。Lima 是 macOS 上成熟的轻量级 VM 方案它让 AI 命令运行在一台独立的小电脑里macOS 系统目录/System、/Library等在虚拟机中完全不可达。对 SSH 连接类瞬态错误桥接层还内置了自动重试保证体验稳定。SandboxSync文件进出沙箱的安检通道虚拟机隔离意味着 AI 无法直接读写你的 Windows 文件那文件怎么进出沙箱呢答案在 sandbox-sync.ts进场对话开始的第一条消息触发沙箱初始化工作区文件被复制而非挂载到 WSL 内的~/.claude/sandbox/{sessionId}目录。干活AI 在整个会话期间只在沙箱副本上操作随时可安全试错。出场当你确认结果满意、请求同步时改动才会写回 Windows 原目录——相当于给 AI 的作业设置了人工验收环节。瘦身同步自动跳过node_modules、.git、dist、日志等无用内容大幅提速。会话删除或应用关闭时沙箱副本随之清理不留残留。安全设计的工程化验证安全机制不能只靠写对了还要靠测试证明。仓库中有多组针对性测试守护这套体系sandbox-command-injection.test.ts验证各类命令注入被拦截path-resolver-containment.test.ts验证路径穿越与符号链接逃逸sandbox-executor-containment.test.ts验证执行器层面的沙箱边界path-containment.test.ts验证底层路径包含判定总结普通用户如何理解这套安全体系用一张心智模型总结防线组件防的是什么第一层PathGuard 路径守卫AI 访问沙箱外的文件、执行危险命令、符号链接逃逸第二层WSL2 / Lima 虚拟机命令直接破坏宿主系统删盘、改系统配置缓冲层SandboxSync 文件同步AI 的破坏性改动未经你确认就落回真实目录三层叠加后Open Cowork 的默认安全姿态是AI 能做的最坏的事只是弄坏一份可以随时丢弃的沙箱副本。这正是它敢于把AI 直接操作文件做成开箱即用体验的底气所在。如果你希望在本地跑起来研究可以通过 README_zh.md 查看安装与构建说明。【免费下载链接】open-coworkOpen-source AI agent desktop app for Windows macOS. One-click install Claude Code, MCP tools, and Skills — with sandbox isolation, multi-model support, and Feishu/Slack integration.项目地址: https://gitcode.com/gh_mirrors/op/open-cowork创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考