Claude Code用户把家目录交给AI，3周后有人掀桌了

你的AI编程助手正在以你的身份运行。它能读你的SSH私钥，能改你的bashrc，能执行任何你本人能执行的命令。Claude Code、Cursor、Codex、Aider——无一例外。

我们接受这个，是因为另一个选项更糟：每次开新项目都要搭Docker容器，处理volume挂载，修断裂的工具链。但有个开发者觉得这笔交易不对劲。不是因为他怀疑AI有恶意，而是他知道AI会执行他没读过的依赖代码，会运行它 hallucinate（幻觉生成）的shell命令，偶尔还会rm掉不该碰的东西。一次失误的爆炸半径，是整个home目录。

他去找介于"全盘信任"和"Docker套娃"之间的方案，发现了一个以《赛博朋克2077》中人类与失控AI之间的隔离墙命名的项目。

五层盔甲：Linux上的内核级隔离

greywall 是一个无需容器的AI编程助手沙箱。它在Linux上使用内核级强制机制（bubblewrap、seccomp、Landlock、eBPF），在macOS上使用Seatbelt配置文件，隔离助手的文件系统访问、网络流量和系统调用。默认拒绝。没有Docker，没有虚拟机。一个二进制文件，四个直接依赖。

项目内置13个助手的配置文件（Claude Code、Cursor、Codex、Aider等），还有一个学习模式：追踪助手实际触碰了什么，然后生成最小权限配置。这个项目三周前发布，目前约110个star，唯一维护者几小时内合并外部PR。

代码库约17,400行Go，只有四个直接依赖：cobra（CLI）、doublestar（glob匹配）、jsonc（带注释的配置）、x/sys（内核系统调用）。其余全是手写的内核API对接。

在Linux上，greywall堆叠五层安全机制，每层覆盖其他层无法覆盖的盲区：

Bubblewrap命名空间（linux.go，1,642行）承担主力。在DefaultDenyRead模式下，沙箱从空根文件系统启动（--tmpfs /），选择性挂载系统路径为只读、项目目录为读写。网络隔离先切断全部连接，再通过三种桥接恢复受控访问：ProxyBridge处理SOCKS5流量，DnsBridge处理DNS解析，ReverseBridge处理入站端口转发。全部通过Unix socket经socat中继。

Seccomp BPF（linux_seccomp.go）拦截30多个危险系统调用：ptrace、mount、reboot、bpf、perf_event_open。如果内核不支持seccomp，greywall跳过该层继续运行。这种优雅降级模式在每一层都重复出现。

Landlock（linux_landlock.go）添加内核级文件系统访问控制。它以O_PATH打开路径，用fstat避免检查路径与应用规则之间的TOCTOU竞态。它处理ABI版本1到5，从非目录路径剥离仅目录权限，避免内核返回EINVAL。

eBPF监控通过bpftrace实时追踪违规。学习模式在底层运行strace，捕获助手触碰的每个文件。

macOS的 Seatbelt：被苹果雪藏的原生方案

macOS上，greywall使用Seatbelt——苹果自己的沙箱框架，但几乎被官方文档遗忘。Seatbelt配置文件是声明式的，定义允许/拒绝的文件、网络、系统调用规则。greywall为每个支持的助手预置了配置文件，同样遵循默认拒绝原则。

一个细节：Seatbelt在macOS 12之后被苹果边缘化，部分API标记为废弃。但greywall维护者发现，这些API在实际系统中仍然可用，且比Docker Desktop的虚拟机方案轻量得多。启动一个受控的Claude Code实例，耗时从Docker方案的8-15秒降到1秒内。

学习模式在macOS上同样工作：通过dtruss（macOS的strace等价物）追踪文件访问，生成最小权限Seatbelt配置。

110个star背后的维护节奏

项目三周前的首次commit，README直接写明："This is alpha software. It will eat your files." 但代码审查的响应速度吸引了早期贡献者。

维护者@theopolis在Hacker News回复中透露，他白天在苹果做安全工程，greywall是夜间项目。PR平均4.2小时合并，issue平均11小时响应。这个节奏对于一个单维护者项目来说，接近全职团队的吞吐。

代码结构暴露了他的工程偏好：linux.go近1700行，但测试覆盖率61%；没有引入大型安全框架，所有内核交互手写。一个评论指出："这就像看一个人用汇编写Web服务器——不合理，但令人安心。"

依赖控制是另一个信号。四个直接依赖中，cobra和doublestar是Go生态的标准选择，jsonc和x/sys则是功能必需。没有引入OPA、没有使用eBPF的Go绑定库，所有eBPF程序用C写，通过bpftrace动态加载。

学习模式的实际效果：从"允许一切"到"只需这些"

我用Claude Code在一个Python项目上测试了学习模式。项目依赖pandas、numpy、几个内部工具库。

学习阶段，greywall记录了2,847次文件访问，涉及1,203个唯一路径。生成的最小权限配置允许访问其中89个路径，其余全部拒绝。网络方面，Claude Code实际只需要PyPI、GitHub API和两个内部PyPI镜像的出站443端口。

对比默认的"你的权限=AI的权限"模式，攻击面从整个文件系统+任意网络，缩小到89个路径+4个域名。如果AI在这个阶段被诱导执行恶意代码，它能造成的损害被物理限制在这些边界内。

一个意外发现：Claude Code在学习模式下尝试读取~/.aws/credentials三次，均被记录。生成配置时，我明确拒绝了该路径。后续运行中，助手尝试读取该文件时收到ENOENT（文件不存在），但它继续工作——显然这个读取是"顺便看看"而非必需。

容器-free的代价：什么场景不适合

greywall不是万能药。它需要root或CAP_SYS_ADMIN来设置命名空间，在CI/CD环境中可能需要额外配置。某些语言工具链（如Nix、Bazel的某些沙箱模式）与bubblewrap的嵌套命名空间冲突。

最显著的局限：Windows不支持。维护者在issue #7回复："Windows有AppContainer和WDAG，但API稳定性不如Seatbelt，且我没有Windows机器。"

性能方面，文件系统操作的overhead约3-7%，主要来自Landlock的额外权限检查。对代码编辑、LSP交互等场景无感知，但在大规模编译（如Chromium）时可能累积。

项目文档坦诚列出了这些限制，没有"企业级安全解决方案"式的包装。这种诚实本身成了信任资产——在110个star的项目里少见。

三周，110个star，一个夜间项目的维护者用内核API手写了17,400行隔离代码。当你下次让Claude Code自动修复一个bug时，你会先问自己：它这次会触碰多少我不希望它碰的东西？