workbuddy沙箱是内置轻量级隔离运行时，随主程序自动部署并默认启用，无需手动安装配置；但必须手动授权系统级文件访问权限，否则任务静默失败。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
WorkBuddy 的沙箱不是独立安装的组件，它随主程序自动部署并默认启用——你不需要手动下载、配置或启动沙箱环境。
为什么沙箱不单独安装？
WorkBuddy 的沙箱是内置的轻量级隔离运行时，基于 CodeBuddy Agent runtime 构建，与客户端深度耦合。它不像 Docker 或 WSL 那样需要用户干预，也不提供 workbuddy-sandbox 或 sandboxctl 这类可调用命令。所有任务（如 Excel 处理、PDF 生成、文件重命名）默认都在该沙箱中执行，只要客户端正常启动，沙箱就已就绪。
常见误解是把它当成 OpenClaw 的 claw-sandbox 插件来装，但 WorkBuddy 已将这部分能力产品化封装，无需额外技能包或 CLI 初始化。
沙箱权限必须手动授权，否则等于没开
沙箱能跑起来 ≠ 能访问你的文件。Windows/macOS 系统级权限未开放时，沙箱会静默失败：任务卡在“准备中”、日志里出现 Permission denied、或返回空结果但无报错。
- Windows：首次启动后，在设置向导中必须勾选「桌面」「文档」「下载」等路径；若跳过，需进入
设置 → 隐私 → 文件系统手动添加 WorkBuddy.exe - macOS：必须前往
系统设置 → 隐私与安全性 → 完整磁盘访问，解锁后拖入WorkBuddy.app；仅勾选“辅助功能”或“屏幕录制”不够 - Linux（非官方支持平台）：沙箱依赖
/tmp可写和usermod -aG dialout $USER，否则串口类 Skill（如硬件控制）直接报Operation not permitted
验证沙箱是否真在工作
别只看界面上的“运行中”状态。真正有效的验证方式是触发一个带副作用的操作，并检查是否发生在隔离上下文内：
- 发指令：
把桌面上的report.xlsx复制一份，重命名为backup.xlsx—— 成功则说明沙箱有读写权限且路径解析正确 - 发指令：
用Python画个折线图，数据来自当前目录下的data.csv—— 若返回图表但data.csv原文件没被修改，说明计算确实在沙箱内完成 - 查看日志：打开
~/.workbuddy/logs/agent-runtime.log（macOS/Linux）或%APPDATA%\WorkBuddy\logs\agent-runtime.log（Windows），搜索sandbox pid=，确认每次任务都生成新进程 ID
沙箱真正的复杂点不在安装，而在权限链路：系统授权 → WorkBuddy 进程继承 → 沙箱子进程继承 → 具体 Skill 调用时的路径白名单校验。任一环断裂，表现都是“任务没反应”，而不是明确报错。
