cplt - 给 AI coding agent 套一层内核沙箱
AI coding agent 的风险不只在于“它会不会改错代码”。更麻烦的是，它能运行命令、读文件、调用包管理器、触发构建脚本，还可能被 README、issue、依赖脚本或 MCP 工具里的提示注入带偏。只靠聊天窗口里的确认按钮，很难覆盖这些子进程和本机凭据边界。
今天推荐的 navikt/cplt 正是为这个问题做的工具。它是一个 Rust 写的单二进制沙箱包装器，可以把 GitHub Copilot CLI、OpenCode、Gemini CLI、Antigravity CLI、Pi 或普通 shell 放进受限环境里运行，让 agent 仍然能在项目目录里写代码，但尽量不能读取 SSH、云厂商、Kubernetes、Docker、密码库等敏感目录，也不能随手访问本机 localhost 服务或执行危险 Git 操作。
发布时 GitHub 搜索结果显示项目约 87 stars、13 forks，主要语言是 Rust，许可为 MIT。仓库创建于 2026-04-09，最近更新时间为 2026-06-15。GitHub releases 的 latest redirect 指向版本 2026.06.15-083243-168c1cb。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | navikt/cplt |
| 定位 | AI coding agent 的本机沙箱包装器 |
| Stars | 约 87 |
| Forks | 13 |
| 主要语言 | Rust |
| 许可 | MIT |
| 最新版本 | 2026.06.15-083243-168c1cb |
它解决的是本机 agent 的信任边界
很多团队现在的默认做法是：把 agent 放在开发者本机，让它在真实仓库里跑测试、安装依赖、改文件、生成提交。这样效率高，但也把本机环境暴露给了 agent 进程和它启动的所有子进程。
cplt 的思路不是把开发流程搬进完整 VM 或 Docker，而是在现有 CLI agent 外面套一层 OS 级限制：
cplt -- -p "fix the tests"
cplt --agent opencode
cplt --agent shell
cplt exec -- npm install在 macOS 上，它使用 Apple Seatbelt / SBPL；在 Linux 上，它使用 Landlock LSM 和 seccomp-BPF。README 写得很直白：项目目录仍然是主要工作区，但凭据目录、敏感文件模式、SSH agent socket、localhost 出站连接、非 443 端口等会被拦住。这样即使 agent 被提示注入诱导去读 ~/.ssh 或扫本机服务，底层进程也会碰到系统级限制。
这和“让模型自觉不要做坏事”是两种完全不同的防线。前者是提示和产品交互，后者是进程实际能不能打开文件、连接 socket、执行二进制。
策略可以进仓库，而不是只靠个人配置
cplt 支持 per-repo policy。团队可以生成并提交 .cplt.toml，把项目需要的权限写清楚，例如是否允许某个端口、是否允许 JVM attach、是否允许 Docker。开发者第一次运行时再显式 trust。
这个设计适合团队场景，因为 agent 权限不再是每个人 shell 里一串不可见的参数。reviewer 可以看见仓库为什么需要某些沙箱放行项，安全团队也可以把默认拒绝项写进模板。
README 还提到命令级 guard：可以拦截 git 和 gh 的高风险动作，例如推送、merge、release、删除等。对 agent 来说，这些动作往往不应该在“修一个测试”这种任务里悄悄发生。把它们变成可审计、可配置的边界，比事后看 git reflog 更稳。
默认防护覆盖了很多真实风险
cplt 的阻断清单很具体，这点比泛泛说“更安全”更有参考价值。它默认关注几类常见泄漏面：
- SSH、GPG、云厂商、Kubernetes、Docker、1Password、Terraform 等凭据目录。
- 项目里的
.env*、.pem、.key等敏感文件模式。 .git/hooks、.git/config、.gitmodules等可能用于持久化或劫持 Git 行为的位置。- 从
/tmp、缓存目录等位置写入后再执行二进制的行为。 - SSH agent socket、本机 localhost 出站连接、非 HTTPS 端口访问。
- 包管理器 lifecycle scripts 和环境变量注入风险。
这些不是每个项目都会全部遇到，但正是 coding agent 最容易跨过的边界：它既像开发者一样能跑工具，又不像开发者一样真正理解本机有哪些长期凭据。cplt 把“项目目录可写”和“整台机器可读”拆开，这是很关键的差别。
它不是 Docker 或 VM 的替代品
值得注意的是，cplt 自己没有把话说满。README 和 security 文档都写了限制。
macOS 侧的文件规则更强，但依赖已被 Apple 标记为 deprecated 的 sandbox-exec。Linux 侧需要 kernel 5.13+ 才有 Landlock，完整 TCP port filtering 还依赖更新内核；而且 Landlock 对已允许目录里的子路径做不到和 macOS 一样的细粒度 deny。项目也明确说，如果你需要完整隔离的文件系统和进程命名空间，Docker 或 VM 仍然有价值。
这反而是 cplt 最值得看的地方：它不是宣称“终极安全”，而是选择一个很实际的中间层。对很多公司笔记本来说，Docker 不一定可用，完整远程开发环境也不一定能马上落地；但一个可以通过 Homebrew 或 release 二进制安装、启动成本接近普通 CLI 的沙箱，更容易先被放进日常 workflow。
和现有 agent 工具的关系
cplt 不是另一个 coding agent。它更像是 agent launcher 和 policy layer。README 中列出的目标包括 GitHub Copilot CLI、OpenCode、Gemini CLI、Antigravity CLI、Pi，以及普通 shell。也就是说，你仍然可以继续使用原来的 agent，只是把启动入口换成 cplt。
这种定位适合渐进采用。团队不需要同时换模型、换 IDE、换 CI，只需要先挑一个仓库试点：
cplt init --write
cplt trust accept --all
cplt config set git_guard.enabled true
cplt config set gh_guard.enabled true然后观察哪些测试、构建、包管理器命令会被阻断，再按需放行。安全工具如果一上来就要求团队重写开发环境，很容易被绕开；cplt 的优势是把默认限制放在 agent 入口处，同时保留必要的 escape hatch。
适合什么场景
cplt 更适合这些团队或个人：
- 已经在本机仓库里使用 CLI coding agent。
- 担心 agent 或子进程读取 SSH、云厂商、Kubernetes、Docker、包管理器凭据。
- 希望把 agent 权限写进仓库 policy，而不是口头约定。
- 想阻止 agent 自动执行
git push、gh pr merge、release 等高风险命令。 - 暂时不想上完整 VM / Docker 沙箱，但希望比裸跑 agent 更有边界。
它不适合被当成唯一安全边界。如果项目处理高敏感代码，或者威胁模型要求强隔离，仍然应该考虑远程一次性环境、容器、VM、权限更窄的凭据和 CI 侧校验。cplt 更像是给日常本机 agent 使用增加一层实用防护。
小结
navikt/cplt 抓住了 AI coding agent 落地后的一个现实问题：agent 越有用，越会接触真实开发环境；而真实开发环境里有太多不应该被随便读取或调用的长期权限。
它用 Rust 单二进制和 OS kernel sandbox 做了一个轻量 wrapper，把项目可写、凭据不可读、网络受限、Git 高风险命令受控这些边界组合起来。对正在把 Copilot、OpenCode、Gemini CLI 等工具放进日常开发流的团队来说，cplt 值得单独拿一个仓库试跑，看看哪些权限是真需要，哪些只是过去裸跑工具时被默认暴露了。