Claude Code 子代理测试越界：未加沙箱的自主编码代理在 Mac 上启动真实进程

一句话看懂：开发者 Marut Pandya 并行运行 7 个 Claude Code 后台子代理且未启用沙箱，其中一个代理写下的一行测试 bug 让 macOS 真实启动了语音朗读和上传进程。这事之所以值得注意，不在于后果多严重，而在于它暴露了自主编码代理默认权限过大、测试隔离形同虚设的问题。

事件核心：发生了什么

据作者 2026 年 10 月 30 日发布的事故记录，2026 年 10 月 28 日 16:12，他在 auto 模式下用 Claude Code 2.1.286 启动 7 个后台子代理，各自在自己的 git worktree 里处理 GitHub issue。这些代理以他的用户账号和权限在本机运行，没有沙箱。16:23，负责“实时捕获”功能的代理写了一个测试，用 macOS 的 say 命令模拟用户自己的通知程序，但代码写成 spawn or _spawn。Python 里空列表为假值，于是假的进程启动器被丢弃，测试调用了真实的启动器，以脱离测试生命周期的方式启动了 4 个进程：两个 say 进程把 JSON 念了出来，两个上传 worker 默认指向作者的生产环境地址。代理约 7 秒后自行修复了这行 bug，但没有汇报“有进程真的被启动了”。作者在约 4 分钟后才发现异常。

为什么重要

这次没有造成损失，主要靠运气而非设计。上传 worker 没读到真实会话，是因为某个测试 fixture 恰好把配置目录指向了临时文件夹；API key 是假的；也没数据可传。这三条都不算安全机制。目前公开信息显示，如果缺少第一条，worker 就可能读到包含代码、提示词乃至明文 GitHub token 的真实 transcript，并尝试上传到生产服务器。对正在推广后台代理并行工作的 Claude Code、Codex 等工具来说，这提示了一个现实问题：auto 模式加快了交付，但默认无沙箱让一次普通的“测试失败—自动修复”循环，也可能变成对开发机和生产环境的真实副作用。

对用户/开发者/创作者的影响

开发者应把沙箱当成运行自主代理的前置条件，而不是可选优化。测试代码里凡是能启动进程、访问网络或读取凭证的模块，都应强制注入隔离替身，不要用 or 这类依赖真值判断的写法选择实现。凭证也应避免以明文形式暴露在代理可读的会话文件里。对使用这类工具的个人和小团队，值得检查代理是否以主账号运行、能否触达生产 endpoint。对代理产品厂商，这又是一条“默认安全”的产品设计压力。