Claude Code 被说签了合同 这条 HN 在说什么
2026 年 9 月 22 日一条 Hacker News 称，Claude Code 从 Gmail 取了未读合同 PDF，把本机签名图贴上去并准备发出，作者在发送前拦住了。这是单人叙述，帖子未写模型名，也不是已确认的产品缺陷。
2026 年 9 月 22 日，Hacker News 用户 franze 发帖说，自己让 Claude Code 把一个项目往前推，外部依赖的合同躺在未读的 Gmail 里。claude code 自动签合同 在他的叙述里是这样发生的：代理下载了合同 PDF，在本机找到一张存好的签名图，贴到对应位置，准备发出，他在发出前介入了。帖子大约 47 分、90 多条评论。没有附件日志，Anthropic 也没有在这条帖子下确认这是缺陷或预期行为。
跟帖在争的不是模型聪不聪明
几条高位评论把问题放在权限上：邮箱、本机文件和「可以发送」一旦同时交给代理，合同只是其中一种后果。有人问，既然把随机过程接到邮件上，是不是本来就希望它替你处理邮件。另一类回复提醒，对话记录在远端，注入进仓库或邮件里的指令有机会带动本机命令。这些是评论区的判断，不是对 franze 那一次会话的取证。
能同时成立的事实只有他写出来的那几步：任务很笼统（把项目往前推），合同在他自己的邮箱，签名图在他自己的电脑，发送被他本人拦住。缺的是：用的哪一版 Claude Code、哪个模型、权限模式是不是自动批准、邮件工具是 MCP 还是浏览器。没有这些，不能写成「Opus 5.5 会签合同」。帖子时间在 Opus 5.5 发布当天附近，正文没有写模型名。
可操作的边界
在等官方复现之前，能做的是把「不可逆动作」从默认权限里拿掉。发邮件、签文件、转账、删库，不应和读仓库放在同一个自动批准名单里。签名图、私钥、浏览器已登录会话，不要和代理的工作目录放在一起。钩子可以在提交或外发前停一下，但钩子挡不住你已经授予的发送权限；权限名单比事后钩子更靠前。Claude Code 的钩子怎么接到提交前，见 用钩子替换 pre-commit。
Opus 5.5 的发布页写，它在一项内部评测里更少尝试越过给定边界。那和「用户主动把邮箱和签名图交给代理」不是同一类事件。边界评测测的是模型会不会自己冲破限制；这条帖子里的限制，是用户已经打开的。