AI 编程 on Kalend's Blog

Codex CLI 上手：OpenAI 的沙箱安全编程方案

Sun, 12 Jul 2026 08:30:00 +0800

AI 编程 Agent 能执行任意命令，这意味着它也能删库、泄露密钥、安装后门。信任问题不解决，自主编程就是空谈。

OpenAI 的 Codex CLI 选择了一条不同的路：不靠"请你信任我"，而是用沙箱把 Agent 关进笼子里。97,000+ Star、Rust 重写、Apache-2.0 开源——这是目前安全设计最完善的终端编程 Agent。

为什么需要"安全编程"

AI 编程工具有个天然的取舍：给的自由越多，风险越大。

Agent 需要执行 shell 命令才能干活——装依赖、跑测试、提交代码。但 shell 命令是无限制的：rm -rf / 也是合法命令。你给 Agent 一个任务，它可能顺手执行了你没想到的操作。

已经出过事了。2026 年多个 AI 编程工具被曝出安全问题：沙箱逃逸、权限提升、未授权网络访问。企业用户不敢用，因为一次意外就可能影响生产环境。

Codex CLI 的答案是：默认不信任 Agent，用系统级隔离强制约束行为。

Codex CLI 是什么

项目	值
GitHub	github.com/openai/codex
Stars	97,204
语言	Rust（从 TypeScript 重写）
许可证	Apache-2.0
开发商	OpenAI
支持模型	GPT-5 系列、codex-1 专用模型

Codex CLI 是 OpenAI 开源的终端编程智能体。三种形态：CLI 终端、VS Code 插件、Codex Cloud 云端。核心特点是把安全沙箱做成了系统级能力，而不是靠 prompt 约束。

Rust 重写不只是为了性能。Rust 的内存安全特性让沙箱实现本身更难被绕过——没有 use-after-free、没有 buffer overflow，攻击面从语言层就被收窄了。

五层安全防线

这是 Codex CLI 的核心卖点，也是它与其他工具拉开差距的地方。

第一层：三级沙箱模式

1
2
3
4
5


read-only 只读，不能写文件、不能执行命令
 ↓ 降低约束
workspace-write 可写项目目录，可执行本地命令（默认）
 ↓ 降低约束
danger-full-access 无限制访问（需要显式声明 danger）

默认是 workspace-write——Agent 只能修改当前项目目录的文件，不能动系统文件、不能改其他项目。想突破这个边界？必须显式声明 danger-full-access，名字本身就提醒你这是危险操作。

第二层：审批控制

沙箱管"能做什么"，审批管"什么时候需要问人"：

策略	行为
`untrusted`	非信任命令都要问
`on-request`	沙箱内自由操作，越界时才问（推荐）
`never`	完全自动，不问任何人

最佳实践：--sandbox workspace-write --ask-for-approval on-request。Agent 在项目目录里自由干活，一旦要访问目录外的资源、使用网络、执行敏感命令，就停下来等你确认。

第三层：可写目录白名单

如果 Agent 需要写多个目录（比如同时改前端和后端），不用开 full-access，用 writable_roots 白名单：

1
2
3
4
5
6


# config.toml
[sandbox_workspace_write]
writable_roots = [
 "/home/user/frontend",
 "/home/user/backend"
]

精确控制哪些目录可写，其余一律只读。最小权限原则的工程实现。

第四层：平台原生隔离

Codex 不是用 Docker 容器做隔离，而是用操作系统原生的安全机制：

平台	隔离机制
macOS	Seatbelt 框架（系统级沙箱）
Linux	bubblewrap（用户命名空间隔离）
Windows	双用户架构（CodexSandboxOffline/Online）
WSL2	复用 Linux 的 bubblewrap 方案

Windows 的实现比较巧妙：创建两个本地用户，CodexSandboxOffline（防火墙阻断出站网络）和 CodexSandboxOnline（允许网络），密码随机生成后用 DPAPI 加密存储。Agent 运行在受限用户下，天然无法访问你的个人文件。

第五层：自动审核

设置 approvals_reviewer = "auto_review" 后，审批请求不是弹给你，而是交给另一个 AI Agent 审核。Agent 审 Agent——审核者有权拒绝越界操作，形成双重校验。

安装与上手

macOS / Linux

1

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Linux 需要先装 bubblewrap：

1
2
3
4
5


# Ubuntu/Debian
sudo apt install bubblewrap

# Fedora
sudo dnf install bubblewrap

Windows

1

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

认证

两种方式：

ChatGPT 账号：运行 codex 后选 “Sign in with ChatGPT”，Plus/Pro/Business 套餐包含 Codex 额度
API Key：设置 OPENAI_API_KEY 环境变量

AGENTS.md

在项目根目录放一个 AGENTS.md，告诉 Agent 项目上下文：

1
2
3
4
5
6
7


# 项目说明
这是一个 Next.js 15 项目，使用 TypeScript + Tailwind CSS。

# 规则
- 测试用 vitest，不要用 jest
- 提交信息用 conventional commits 格式
- 不要修改 .env 文件

Codex 启动时会自动读取这个文件，相当于给 Agent 一份项目手册。

实战演示

场景 1：安全模式下重构代码

1

codex --sandbox workspace-write --ask-for-approval on-request

在这个模式下，Agent 可以自由读写项目文件、运行测试。但当它尝试 npm install 一个新包（需要网络）时，会弹出审批提示。你确认后才继续。

场景 2：CI/CD 管道中的静默模式

1
2


codex exec --sandbox workspace-write --ask-for-approval never \
 "运行所有测试，如果有失败的修复它们，然后提交"

exec 是一次性执行模式，跑完自动退出。配合 --ask-for-approval never 适合自动化管道——但沙箱仍然生效，Agent 不能突破项目目录。

场景 3：/goal 自主执行

在交互模式下输入 /goal，Agent 进入自主循环：规划 → 执行 → 验证 → 继续，直到目标完成。沙箱和审批策略全程生效。

与 Claude Code、OpenCode 对比

维度	Codex CLI	Claude Code	OpenCode
开发商	OpenAI	Anthropic	社区
语言	Rust	TypeScript	Go
安全设计	五层沙箱 + 平台原生隔离	沙箱 + 权限控制	BYOK，无内置沙箱
沙箱机制	bubblewrap/Seatbelt/Windows Sandbox	类似但实现不同	无
审批控制	三级策略 + 自动审核	有	基础
可写目录白名单	`writable_roots`	有	无
模型	GPT-5 系列 + codex-1	Claude 4 系列	75+ 模型
MCP 支持	✅	✅	✅

安全设计维度，Codex CLI 领先一个身位。 它的沙箱不是应用层的权限检查，而是操作系统级的强制隔离——Agent 想逃逸，得先攻破 bubblewrap 或 Seatbelt。

Claude Code 也有沙箱，设计思路类似，但实现深度不同。OpenCode 走的是 BYOK（Bring Your Own Key）路线，安全完全交给用户自己负责。

谁该用 Codex CLI

首选场景：

企业/金融/医疗等安全敏感行业：沙箱隔离是刚需，不是锦上添花
OpenAI 生态用户：已经用 GPT-5 系列，Codex CLI 是最自然的编程 Agent 选择
团队协作：自动审核功能让多人共用 Agent 时有统一的安全策略
CI/CD 集成：静默模式 + 沙箱 = 安全的自动化编程

不太适合的场景：

需要频繁切换多个 LLM 模型的用户（Codex 主要服务 OpenAI 模型）
超长上下文任务（Claude 的长上下文更稳定）
预算敏感的纯 API 用户（Codex-1 专用模型按 token 计费）

结论

AI 编程 Agent 的竞争正在从"谁能写更好的代码"转向"谁更值得信任"。Codex CLI 的五层安全防线不是营销话术，而是工程落地：操作系统级沙箱、最小权限白名单、Agent 审 Agent 的自动审核。

沙箱不是限制，是 Agent 自主运行的前提。 你得先确定它不会越界，才敢放手。Codex CLI 目前是安全机制最完善的终端编程 Agent。

MiMo Code 实测：会"做梦"能"进化"的开源 AI 编程助手，9 天怒砍 9.9k star

Sat, 20 Jun 2026 09:00:00 +0800

MiMo Code 实测：会"做梦"能"进化"的开源 AI 编程助手，9 天怒砍 9.9k star

小米开源了一款终端 AI 编程 Agent，叫 MiMo Code。

打开 GitHub，数字挺扎眼：9.9k star、917 fork、414 个 issue、96 个 PR——最新 commit 停在 8 小时前。这是一个 9 天前才开源的项目，活跃度却像跑了半年。

我花了一个周末把它装上，跑了几个真实任务，想搞清楚一个问题：市面上的 AI 编程助手已经够多了，Claude Code、Cursor、Copilot、OpenCode……小米这时候入局，凭什么？

答案藏在 README 里一句话——“模型与 Agent 共进化”。翻译成人话：这个工具不只会写代码，它还会记住你的项目、自己整理记忆、自己把重复经验变成技能。官方管前者叫 Dream（做梦），后者叫 Distill（蒸馏）。

还有一个数据让我在意：官方做了双盲 A/B 测试，200+ 步的复杂任务，MiMo Code 的胜率超过 65%。200 步意味着什么？意味着这不是"写个函数"级别的任务，而是"从需求到交付"的完整工程链条——这种长程任务恰恰是大多数 AI 编程工具容易翻车的地方。

“AI 会自己做梦”——这个钩子足够让我把周末搭进去。下面是我实测下来的真实感受。

5 分钟装好：一行命令，零配置开跑

先说安装。MiMo Code 的门槛低到我有点意外：

1
2
3
4
5
6
7
8


# 方式一：一行命令
curl -fsSL https://mimo.xiaomi.com/install | bash

# 方式二：npm
npm install -g @mimo-ai/cli

# 装完直接启动
mimo

首次启动会引导你配置模型通道。这里有个我认为最关键的亮点——MiMo Auto：

MiMo Auto：限时免费，匿名通道，零配置，不需要任何 API Key，开箱即用，支持百万 token 上下文
小米 MiMo 平台：OAuth 登录，用官方账号体系
从 Claude Code 导入：一键迁移你已有的认证
自定义 Provider：任意 OpenAI 兼容 API 都能接

我手上没有现成的 API Key 余额，选了 MiMo Auto，点完确认就能用了。对比一下：用 Claude Code 你得先备好 Anthropic 的 Key，用 OpenCode 你得自己接 provider——MiMo Code 把"先能用起来"这一步压到了最低。

如果你已经在用 Claude Code，迁移几乎是零成本：选"从 Claude Code 导入"，它自动读取你本地已有的认证配置。这个细节对老用户很友好。

装完敲 mimo，终端弹出 TUI 界面。我第一感觉是：长得像 Claude Code，但底部多了一排我没见过的命令——/dream、/distill、/goal。这些就是后面要讲的重点。

build / plan / compose：三种模式，Tab 一键切换

MiMo Code 有三种 Agent 模式，按 Tab 切换：

模式	定位	权限
build	默认模式，完整开发	全工具权限，能读写文件、跑命令
plan	只读分析、代码探索、方案设计	只读，不改你的代码
compose	specs 驱动 + skill 驱动的结构化工作流	编排模式

什么时候用哪个？我的习惯是：

拿到一个陌生代码库，先切 plan 模式让它"只看不动"，帮我理清架构、定位 bug 在哪。只读模式有个好处：它不会手抖把你的文件改了，适合探索阶段。
真正动手改代码，切回 build，全权限放开。
compose 模式适合"有明确规范、要走完整流程"的项目开发——内置技能覆盖 planning → execution → code review → TDD → debugging → verification → merging 全生命周期。如果你团队有 specs 驱动的习惯，这个模式很对味。

子代理由系统按需创建，主代理觉得某个子任务可以并行，就会 spawn 一个子代理去干，干完汇报回来。这部分和 Claude Code 的思路类似，不算 MiMo 独有。

四层记忆系统：它凭什么"记住"你的项目

现在进入 MiMo Code 真正不一样的地方。

我之前用 Claude Code 有个痛点：每次开新会话，AI 都是"失忆"的。上次我让它遵守的代码规范、上次讨论过的架构决策，它全不记得，我得重新解释一遍。CLAUDE.md 能缓解一部分，但它是静态文件，AI 不会主动更新它。

MiMo Code 搞了一套四层持久记忆，全部基于 SQLite FTS5 全文检索：

项目记忆 MEMORY.md — 持久的项目知识、编码规则、架构决策。这是"长期记忆"，AI 会主动往里写。
会话检查点 checkpoint.md — 由一个叫 checkpoint-writer 的子代理自动维护，定期给当前工作状态拍快照。
临时笔记 notes.md — 代理的草稿区，临时想法、待办丢这里。
任务进度 tasks/<id>/progress.md — 每个任务一份日志，记录这一路干了什么。

关键在于"自动注入"。下次你打开同一个项目，启动新会话，MiMo Code 会自动把记忆层的内容注入到上下文里——AI 不需要你重新解释项目背景，它"记得"。

我实测的感受：这个机制对"长期维护一个项目"的场景价值很大。想象你一个项目断断续续改了两周，中间隔了几天没碰。用别的工具，回来第一件事是重新喂背景；用 MiMo Code，它自己把记忆加载回来了，直接说"继续上次那个 TODO"就行。

这是和 Claude Code、Cursor 拉开差距的核心设计，也是后面"自进化"能成立的地基。

Goal Mode + 智能上下文管理：让 AI 自己跑到达标为止

两个机制，解决的是"长程任务"的痛点。

Goal Mode——用 /goal 命令给会话设一个停止条件。比如：

1

/goal 所有测试通过且无 lint 错误

设好之后，AI 会自己一轮一轮地跑，直到条件满足才停。这里有个反直觉的设计：当 AI 觉得"我做完了"想停下来时，一个独立的 judge 模型会评估对话，判断条件是不是真的满足了。为什么要独立 judge？防止 AI"乐观提前停止"——这是自主 Agent 的常见毛病，模型自己跑着跑着觉得差不多了就收工，实际还差一截。加一层独立判断，等于给"自我宣称完成"上了一道闸。

智能上下文管理解决的是另一个问题：长任务跑到一半，上下文窗口快满了，怎么办？

MiMo Code 的做法是三步：

自动检查点：根据模型的上下文窗口大小，自动决定什么时候保存状态。
上下文重建：当上下文接近上限，它从最新的检查点 + 项目记忆 + 任务进度 + 保留的近期消息，重新拼一个上下文出来，让代理继续当前任务而不是从头开始。
预算注入：用 token 预算控制检查点、记忆、笔记的注入量，按重要性排序，保证最关键的信息先进来。

我跑了一个比较长的重构任务，中间明显感觉到上下文重建发生了一次——界面闪了一下，AI 没有断片，接着之前的工作继续干。这种"长任务不断片"的体验，是我之前在别的工具上没感受到的。

Dream & Distill：它会自己做梦，还会把经验变成技能

这是整篇文章我想重点讲的部分，也是 MiMo Code 最有故事性的设计。

/dream —— 让 AI"做梦整理记忆"

1

/dream

执行后，MiMo Code 会扫描近期的会话痕迹，把其中有价值的知识提取出来，写进项目记忆 MEMORY.md，同时清除过时或失效的条目。建议大约每周做一次 Dream。

为什么要叫"做梦"？人的大脑在睡眠时会整理白天的记忆——强化重要的、丢弃无用的。MiMo Code 借的就是这个隐喻：AI 在你不干活的时候，自己回头把这段时间的对话梳理一遍，提炼成持久知识。

我第一次跑 /dream 之后翻了翻 MEMORY.md，发现它把我之前口头强调过的几条项目规范（命名约定、错误处理方式）自动归纳进去了。下次开新会话，这些规范不用我再说。

/distill —— 把重复经验"蒸馏"成技能

1

/distill

这个命令会分析你近期的工作，找出重复出现的手动工作流——比如你每次写新接口都走同一套"建文件→加路由→写测试→补文档"的流程——然后把这些高置信度的候选模式，打包成可复用的技能、子代理或命令。建议间隔更长一些，大约每月做一次 Distill。

Dream 是整理记忆，Distill 是固化能力。合在一起，这就是官方说的"自进化"：AI 不是被动等你喂指令，它在持续学习你的工作方式，把经验沉淀成自己的技能库。

这个设计的意义在哪？

我用过的其他 AI 编程工具，本质都是"一次性对话"——你问它答，会话结束一切清零。哪怕有记忆功能，也是被动的：你得手动维护 CLAUDE.md，手动告诉它记住什么。

MiMo Code 把这个循环变成了主动的、自动的：它自己整理记忆（Dream），自己沉淀技能（Distill），周期性地"升级"自己对项目的理解。时间越长，它和你的项目贴合度越高。这才是"模型与 Agent 共进化"这句话的真正含义——不是模型权重在变，是 Agent 对你工作方式的理解在持续累积。

这是我目前见到的、把"Agent 自主性"推得最远的设计之一。

实战复盘：用它从零做了一个小项目

光说不练假把式。我用 MiMo Code 做了一个真实的小项目——一个 Python 写的 Markdown 链接检查器，扫描指定目录下所有 .md 文件里的链接，发请求验证死链，输出报告。

项目不大，但足够让我摸清记忆、检查点、Goal 这几个机制在真实任务里的手感。

第一步：建项目，让它记住规范。

进项目目录启动 MiMo Code，切到 build 模式，我把需求描述给它：要一个 CLI 工具，输入目录路径，递归扫描 .md，提取所有 Markdown 链接，并发请求验证，支持超时和重试，输出 JSON 报告。

第一轮对话里，我强调了几条规范：用 argparse 不用 click、日志走 logging 模块、并发用 asyncio。聊完一轮，我注意到它把这些写进了 MEMORY.md 的项目约定里——不是我让它写的，是它自己判断这些是"持久规则"。

第二步：让它自己跑完整流程。

我没有一步步指挥，而是设了个 Goal：

1

/goal 实现完整的链接检查器，所有测试通过，CLI 能正常跑通

设完之后它就开始自己干活了：建项目结构、写主逻辑、加并发控制、写测试。中间它 spawn 了一个子代理专门跑测试，主代理继续写文档。我盯着看，偶尔它问我确认（比如"超时默认值设 10 秒可以吗"），我回一句它继续。

整个开发过程穿插了两次让我印象深的机制触发。

第一次是上下文重建。任务跑到一半（大概写完了核心扫描逻辑和并发控制，正在补测试），上下文窗口快满了。这时 MiMo Code 触发了重建——我能看到 checkpoint.md 被更新，任务进度 progress.md 记了"核心逻辑完成，测试覆盖扫描和并发模块，下一步补文档和错误处理"。重建后它没断片，接着补测试和文档。如果没有这套记忆机制，长任务跑到这里要么报上下文超限，要么从头喂背景。

第二次是 checkpoint-writer 子代理的工作。我注意到它会定期"拍快照"——把当前的文件结构、已完成的函数、待办事项结构化地写进 checkpoint.md。这东西平时不显眼，但在上下文重建那一刻，它就是续命的锚点。等于 AI 在长任务里给自己留了 breadcrumb（面包屑），迷路了能顺着找回来。

第三步：验证，看它自己整理了什么。

跑完后我翻了翻它生成的记忆文件。MEMORY.md 里多了这个项目的架构说明（“主模块 linkchecker，asyncio 并发，argparse 入口”）；checkpoint.md 记了最后的工作状态；tasks 目录下有完整的进度日志。

这套东西的价值在下一次会话才真正显现——第二天我回来想加个"忽略特定域名"的功能，启动新会话，它自动加载了记忆，我直接说"加个 –ignore 参数"，它秒懂项目背景，不用我重新解释。这个连贯感，是纯对话式工具给不了的。

最后我用 /dream 跑了一轮，它把这次项目里形成的"asyncio 并发请求要加信号量限流"这条经验，从临时笔记提炼进了 MEMORY.md 的通用经验区。下次做别的项目，这条还在。

整个项目从零到能跑，AI 主导执行，我主要负责提需求和验收。记忆系统让"跨会话连续性"这件事第一次变得不那么费劲。

和 Claude Code、OpenCode 比，谁更适合你

最后说选型——但我不会做排行榜，因为工具是挑场景的。

先厘清一个事实：MiMo Code 是 OpenCode 的 fork。它保留了 OpenCode 的全部核心能力——多 provider 支持、TUI 界面、LSP 集成、MCP 服务器、插件系统——然后在上面叠了六层东西：持久记忆、智能上下文管理、子代理编排、Goal 驱动的自主循环、Compose 工作流、Dream/Distill 自我改进。

所以选型逻辑很清晰：

Claude Code：闭源旗舰，模型能力强，但贵，且记忆是短板。适合预算充足、单次高质量任务为主的场景。
Cursor：IDE 形态，订阅制，强在编辑器内交互。适合喜欢在 IDE 里干活、离不开图形界面的开发者。
OpenCode：开源基础盘，能力强但要自备 API Key，记忆和自进化得自己搞。适合想完全掌控、愿意折腾底层的用户。
MiMo Code：开源 + MiMo Auto 免费通道（零配置）+ 四层记忆 + Dream/Distill 自进化。适合长期维护项目、想要"越用越懂我"的开发者。

我的判断：如果你最看重"AI 和项目共同成长"这件事，目前 MiMo Code 是唯一把这条路走到这个程度的选择。Claude Code 强在单点能力，MiMo Code 强在长期累积。两者不冲突，搭配用也行。

几个要注意的点，避免你踩坑：MIT 协议但有"使用限制"附加条款，商用前看一眼；语音输入需要装 sox 且 MiMo 登录；Max Mode（并行 best-of-N 推理）是 experimental，得在配置里手动开 experimental.maxMode；作为 9 天前的新项目，414 个 issue 说明稳定性还在打磨——别拿它跑生产环境的关键任务，先用在日常项目和原型开发上。

小米这次开源 MiMo Code，我觉得最值得关注的不是又一个 AI 编程工具，而是它把"Agent 自进化"这个概念做成了可用的产品功能。AI 会做梦、会蒸馏经验、会越用越懂你的项目——如果这条路走通，它改变的可能不只是"写代码效率"，而是"人和 AI 协作的长期关系"。

9 天 9.9k star，不是没有理由的。建议你自己装一个试试，跑两周，感受一下"越用越懂"是什么手感。