当开发者给终端里的 Claude Code、Cursor 或 Aider 加上 --dangerously-skip-permissions 参数时，终端就变成了一把没有保险栓的左轮手枪。模型一次轻率的幻觉可以敲出 rm -rf ~，一段潜藏在第三方开源依赖里的 Prompt 注入代码，也能在一秒钟内将 ~/.ssh 密钥打包带走。
在容器化与微虚拟机动辄要求配置 Dockerfile、忍受环境构建摩擦的背景下，开发者 wrr 于 2026 年 3 月 24 日在 Show HN 提交了名为 Drop 的轻量级 Linux 沙箱工具，并在 3 月 29 日发布了更新迭代。它直击痛点的主张非常单纯：不用 root 权限，不重新构建镜像，直接复用宿主机既有的开发环境，像 Python 的 virtualenv 一样随用随建。但把系统级隔离包装成无痛外壳之后，看似无虞的沙箱究竟能不能兜住 Agent 的野蛮操作，底层的工程代价与安全盲区值得仔细算一笔账。
零镜像穿透：系统级 virtualenv 怎么偷巧
Drop 的核心思路是把传统容器中沉重的环境封装剥离，只留下隔离层。它基于 Linux 用户命名空间（user namespace），同时切分出独立的挂载、PID、IPC、网络以及 cgroup 命名空间。与传统特权方案不同，Drop 在拉起沙箱进程前会主动丢弃所有特权能力，因此沙箱内的程序哪怕拿到内部的虚拟用户身份，也无法在命名空间内执行挂载操作。这种设计带来的硬性限制十分明确：沙箱内部不支持嵌套运行任何依赖 user namespace 的容器程序，开发者无法在 Drop 内部直接调用 Podman。
为了免去容器镜像的构建和维护，Drop 采取了极其激进的文件系统穿透策略。它将宿主机的 /usr、/bin、/lib 和 /sbin 全部以只读形式暴露给沙箱内部，开发者在外部配置好的编译器、解释器与开发工具链无需任何二次安装即可立即可用。与此同时，Drop 阻断了对宿主机真实主目录的访问，通过在沙箱内部挂载私有的虚拟目录，让恶意代码或幻觉指令至多只能在虚构的根目录里折腾。
针对高危对抗环境，Drop 还引入了基于 Google gVisor 的 runsc 运行时作为可选配置。在原生模式下，沙箱仍旧共享宿主机内核，无法防御针对未修补内核漏洞的本地提权；而在 gVisor 模式下，程序发起的所有系统调用都会被用户态虚拟内核接管与模拟。这种双重护盾能够大幅收缩内核攻击面，但在小文件密集 I/O 与高频系统调用场景下，性能损耗显而易见，这并不是一项无损的工程开关。
默认配置暗雷：只读不等于保密
官方宣称只要在 Drop 里运行命令，就能放开 Agent 的危险权限执行。但审视其默认机制与网络策略，这种安全承诺存在着巨大的认知错位。
首当其冲的是网络边界。Drop 采用 pasta 提供非特权用户态网络，在其默认的 isolated 模式下，沙箱确实切断了对宿主机 localhost 服务的请求，防止 Agent 擅自探查宿主机本地的调试端口或数据库；但关键在于，该模式默认允许访问公网。只有显式将网络切换至 off 模式，网络通信才会被完全切断。
与默认公网出站叠加在一起的，是配置文件映射机制的隐患。为了维持终端环境的顺手体验，Drop 允许将 .bashrc、.zshrc 或 .gitconfig 以只读方式挂入沙箱。系统设计者往往将防御重点放在防篡改上，却忽视了保密性。只读挂载确实保证了 Agent 无法覆盖配置文件，但根本防不住读取。一旦开发者的 shell 启动文件或 git 配置中存在硬编码的私有仓库 Token、API Key 或内网凭据，注入了恶意指令的 Agent 依然能够读取明文，并通过默认开启的公网通道将密钥外流。
关得住删库的指令，往往关不住带外回传的数据。
此外，Drop 在资源控制与生命周期管理上也留下了宽松的缝隙。虽然工具初始化时创建了独立的 cgroup 命名空间，但在其公开的 TOML 配置规范中，至今未提供资源配额硬限制。无论是 CPU 核心占用、物理内存上限、最大进程数（pids limit），还是磁盘使用量，都缺乏边界约束。沙箱内失控的代码完全可以通过高并发进程耗尽宿主机资源，形成本地拒绝服务。
而在存储设计上，Drop 标榜灵感来自 virtualenv 的即用即弃（disposable），底层行为却默认保持持久化。沙箱中生成的独立 /home、/var 和 /tmp 目录在会话退出后并不会被清理，所有数据都会静默保留在磁盘上，直到用户在宿主机手动执行 drop rm。如果依赖管理工具在沙箱中安装了恶意轮子或供应链投毒包，这些危险文件会长期沉淀在私有目录内，随时等待下一次调用。
- 风险.默认的
isolated网络模式依然具备外网出站能力，配合只读挂载的 shell 配置，极易成为凭证泄露的外溢通道。
工作区毒化：不可避免的延迟逃逸
在所有隔离手段中，最棘手的问题往往不是来自 Linux 命名空间本身的穿透漏洞，而是编程场景本身的逻辑死结。
Drop 默认将初始化项目目录设为可写，同时机敏地把项目内部的 .git 目录设为只读挂载。这项配置原本旨在防范版本控制元数据被破坏或提交历史被恶意抹除，但它挡不住工作区毒化。一个失控的 Agent 或被提示词操纵的依赖，不需要破坏 git 历史，只需要顺手在 package.json 的 preinstall 脚本、项目的 Makefile、或者目录下的 .envrc 配置文件里追加一行后门指令。
开发者的典型工作流往往是：在沙箱内完成编码生成，随后退出沙箱，回到宿主机终端运行构建、测试或调试命令。就在敲下回车的那一瞬间，被污染的构建脚本直接在宿主机权限下触发，宿主机的环境变量、公私密钥和网络权限拱手相送。
古人讲求审时度势，更讲求内外防范。轻量沙箱能隔绝进程在运行期间越轨，却很难阻止它在被允许写出的代码文件里留下暗桩。依赖穿透宿主机环境带来的敏捷性，天然就与绝对安全站在对立面。Bubblewrap 过于底层导致配置成本高昂，Rootless Podman 虽然隔离完备却带来了沉重的镜像与上下文切换成本，Drop 踩中了中间生态位，但使用者绝不能产生有了沙箱便可高枕无忧的幻觉。
- 建议.在 Drop 中运行全自主 Agent 时，应主动在 TOML 中将网络设为断网模式（
net: off），严禁挂载包含私钥的 shell 配置，并在退出后使用隔离的分支工作区审查代码。
真正坚固的工程防线从来不是单一工具的开箱即用，而是一套完整的防御纵深。Drop 省去了构建容器的时间，但把审查权限、防范延迟逃逸的警惕心，重新交还给了屏幕前的工程师。