Codex CLI速查表里列了一堆斜杠命令和快捷键，但“命令会敲”和“知道什么时候该用哪个命令”之间差着一整套工作流认知——从安装到第一次让Codex改代码，新手最容易在“安全模式理解”这一步翻车，所谓“安全模式”到底是指沙箱、批准策略还是网络权限，三者之间的交互关系有没有一张能贴在墙上的决策图？

1. 问题的真正起点：速查表遮蔽了什么

打开任意一份 Codex CLI 速查表，你会看到整齐的两栏：左边是斜杠命令，右边是快捷键。/model 切换模型，/approvals 调整批准策略，/diff 查看改动，Ctrl+J 换行，Esc 中断。这份表本身没有错，错的是它给人的暗示：仿佛学会这些命令，就学会了这个工具。

但真实的使用现场是另一回事。一个刚装好 Codex CLI 的开发者，第一次让模型改代码时，往往会在三个地方卡住：模型提出要执行 npm install，要不要批准？它想访问网络拉取依赖，会不会被沙箱拦住？它说"我需要写入这个文件"，而当前目录在沙箱里是只读的，这算正常还是配置错了？这三个问题分别对应批准策略、网络权限、沙箱模式，而速查表把它们压缩成了几个孤立的命令名。

本文的核心判断：Codex CLI 的学习曲线不在命令层，而在权限层。命令是"动词"，权限是"语法"。不掌握语法，动词越多越容易出错。

这个判断并非修辞。从工程角度看，Agentic Coding 工具与传统 IDE 插件的根本差异在于：模型不再只"建议"代码，而是被授予了执行能力——它可以运行 shell、写文件、发起网络请求。授予多少、在什么条件下授予、如何收回，构成了一个权限设计问题。速查表跳过了这个问题，所以新手最容易在"安全模式理解"这一步翻车。

本文要做的，是把这一步补上。我们提出一条贯穿全文的分析主线：把"安全模式"从单一开关还原为三维权限空间，并用决策图把空间切分成可操作的工作流区域。所有后续章节——安装、配置、命令语义、团队策略——都服务于这条主线。

2. 背景与问题定义：Agentic CLI 的权限困境

2.1 从补全到代理：能力边界的迁移

要理解权限问题为何突然变得重要，需要先看清工具形态的演变。早期的代码补全工具（如 2021 年前后的 Copilot 类产品）输出的是文本建议，是否采纳由人决定，工具本身不触碰文件系统。这一阶段的权限风险几乎为零，因为执行权始终在人手里。

Agentic CLI 改变了这一点。以 Codex CLI 为代表的命令行代理，其设计目标是"在终端里完成一次完整的工程任务"：读代码、改代码、跑测试、修错误。这意味着它必须获得文件写入与命令执行能力。OpenAI 在 Codex CLI 的公开文档中明确将其定位为"在本地终端运行的编码代理"，并围绕这一能力设计了沙箱与批准机制（OpenAI, 2025）。

本文评述：能力边界的迁移不是渐进式的，而是阶跃式的。一旦工具获得执行权，"它会不会做错事"就从哲学问题变成了工程问题——需要具体的隔离机制、审批流程和审计记录。速查表之所以失效，正是因为它诞生于"建议型工具"的认知框架，却要服务于"执行型工具"的使用场景。

2.2 三类典型事故模式

在讨论机制之前，先界定问题。根据公开的社区讨论与工具文档中披露的失败案例类型，Agentic CLI 的权限相关事故大致可归为三类：

事故类型	触发条件	典型后果	对应权限轴
越界写入	沙箱为可写但范围过大，模型改动工作区外文件	配置被覆盖、系统文件受损	沙箱
静默执行	批准策略设为全自动，危险命令未经确认执行	误删、误提交、误推送	批准策略
外联泄露	网络权限开放，模型将代码片段发往外部端点	敏感信息外流、供应链风险	网络权限

这张表的排列顺序不是随意的。它对应了本文主线的第一步：把模糊的"不安全"拆成三个可分别治理的维度。一旦拆开，每个维度都有独立的配置手段和独立的失效模式，治理就从"小心一点"变成了"按轴设防"。

2.3 为什么"安全模式"这个词本身是陷阱

社区里常有人问"Codex 的安全模式怎么开"。这个问题预设了"安全模式是一个开关"，但实际配置界面里并没有一个叫"安全模式"的单一选项。你看到的是 --sandbox、--ask-for-approval、网络开关等分散的参数。

本文评述：术语的模糊性会直接转化为操作错误。当用户以为存在一个"安全模式"开关时，他会倾向于"打开它然后不管"；而当他知道安全是三个维度的组合时，他才会去检查每个维度的当前取值。这不是文字游戏，而是认知负荷的重新分配——把"记住一个开关"换成"理解一个空间"，短期更累，长期更稳。

因此，本文拒绝使用"安全模式"作为单一概念，而是用"权限配置（permission posture）"指代三轴取值的组合。后文所有讨论都建立在这个定义之上。

3. 权限三轴模型：沙箱、批准策略、网络权限

3.1 三轴的定义与正交性论证

先给出严格定义，再论证它们为何应当被视为正交维度。

沙箱（sandbox）：限制进程可访问的文件系统范围与系统调用集合的隔离机制。在 Codex CLI 的语境下，它回答的是"模型发起的操作在物理上能触及哪里"。常见取值包括只读、工作区可写、全盘可写等档位。

批准策略（approval policy）：决定哪些操作在执行前需要人工确认的规则集合。它回答的是"模型发起的操作在流程上要不要人点头"。常见取值包括逐条确认、仅危险操作确认、全自动等档位。

网络权限（network access）：是否允许代理进程发起外部网络连接，以及允许的目标范围。它回答的是"模型发起的操作能不能和外界通信"。

三者的正交性可以从一个反例证明：假设沙箱设为只读、批准策略设为全自动、网络关闭。此时模型能读代码、能自动执行只读命令、但不能写文件也不能联网。再假设沙箱设为工作区可写、批准策略设为逐条确认、网络关闭。这两组配置在"写入能力"上完全不同，但"网络能力"相同——说明沙箱与网络可以独立变化。同理，批准策略可以在沙箱不变的情况下从逐条确认切到全自动，说明批准策略与前两者也独立。

三轴模型的形式化表述：权限配置 P = (S, A, N)，其中 S ∈ {只读, 工作区可写, 全盘可写}，A ∈ {逐条确认, 危险确认, 全自动}，N ∈ {关闭, 白名单, 开放}。三轴取值可自由组合，共 27 种配置姿态。

本文评述：正交性不是数学上的绝对性质，而是工程上的近似。某些组合在实践中会被工具默认约束（例如全自动批准通常不建议搭配全盘可写），但这恰恰说明三轴模型的价值——它把"哪些组合危险"变成了可以显式讨论的规则，而不是隐藏在默认值里的隐式约定。

3.2 沙箱的机制细节：从 chroot 到容器化隔离

沙箱的技术谱系值得单独展开，因为它决定了"只读"和"可写"到底意味着什么。传统上，文件系统隔离有若干层次：chroot 改变根目录但不隔离系统调用；命名空间（namespace）隔离挂载点与进程视图；seccomp 过滤系统调用；容器运行时（如 Docker、Podman）组合上述机制提供完整隔离。

Codex CLI 在 Linux 上倾向于使用内核提供的轻量隔离原语，在 macOS 上则依赖系统自带的沙箱框架（如 Seatbelt 的 sandbox-exec 机制）。这一设计选择有明确的工程理由：CLI 工具需要低启动开销，完整容器化的冷启动成本（数百毫秒到数秒）会破坏交互体验。Apple 的沙箱机制在 macOS 上提供了基于策略文件的细粒度控制，其设计思想可追溯到早期关于最小权限原则的系统安全研究（Saltzer & Schroeder, 1975）。

本文评述：轻量隔离与强隔离之间存在明确的权衡。轻量隔离启动快、与宿主环境耦合紧，但隔离边界相对薄；容器化隔离边界厚，但交互延迟高。Codex CLI 选择前者，意味着它的沙箱更适合"防止误操作"而非"防御恶意代码"。理解这一点很关键——如果你要让代理处理来源不可信的代码，轻量沙箱不应被视为充分防护。

3.3 批准策略的粒度问题

批准策略看似简单，实则涉及一个被低估的设计维度：粒度。粗粒度策略只有"全自动"和"全手动"两档，细粒度策略则按操作类型分级。Codex CLI 的批准策略大致落在中间：它区分"读操作"与"写/执行操作"，对后者要求确认。

粒度设计的核心矛盾是审批疲劳。如果每个操作都要确认，用户会在第十次确认后开始无脑点"是"，此时批准策略形同虚设。这一现象在安全人机交互研究中被称为"警报疲劳"（alert fatigue），在入侵检测系统领域有大量实证（Alahmadi et al., 2022）。

本文评述：批准策略的有效性不取决于它"拦住了多少操作"，而取决于"用户是否认真看了被拦的操作"。设计良好的批准策略应当把确认次数控制在用户注意力预算之内——这正是后文决策图要解决的问题：不是所有场景都需要逐条确认，关键是让确认发生在真正需要的地方。

3.4 网络权限：最容易被忽视的一轴

在三轴中，网络权限最容易被新手忽略，因为它的失效是"静默"的。沙箱越界会报错，批准被拒会有提示，但网络请求一旦被允许，数据外流不会产生任何可见信号。

网络权限的配置通常有三种形态：完全关闭（代理无法联网，依赖需预装）、白名单（仅允许特定域名，如包管理器源）、开放（允许任意出站连接）。从供应链安全角度看，白名单是较稳妥的折中——它允许 npm install 这类必要操作，同时阻断向未知端点的数据发送。

本文评述：网络权限与沙箱的交互常被误解。有人以为"沙箱开着就安全"，但如果沙箱允许工作区可写且网络开放，模型完全可以读取工作区内的密钥文件并发往外部。沙箱管的是"能碰什么"，网络管的是"能送什么"，两者缺一不可。这一组合风险在 OWASP 的 LLM 应用安全清单中被归入"敏感信息泄露"类（OWASP, 2025）。

3.5 三轴的耦合效应：1+1+1 > 3

正交不等于无关。三轴取值组合后会产生非线性的风险放大效应。举一个具体的耦合链：沙箱设为工作区可写 → 模型可以修改 package.json → 批准策略设为全自动 → 修改无需确认 → 网络开放 → 模型执行 npm install 拉取被篡改的依赖。四个环节单独看都不算致命，串起来就是一条完整的供应链攻击路径。

本文评述：这条耦合链说明，权限配置不能逐轴独立优化，必须做组合审计。后文的决策图正是为此设计：它不告诉你"每一轴该设什么"，而是告诉你"哪些组合是危险的、哪些组合适合哪些场景"。

4. 从安装到第一次改码：一条可复现的路径

4.1 安装与认证：把环境准备好

Codex CLI 的分发方式以 npm 包为主，这决定了前置条件：Node.js 运行时。安装命令本身很短，但环境准备有几个容易踩的点。

# 确认 Node 版本（建议 18 及以上）
node --version

# 全局安装 Codex CLI
npm install -g @openai/codex

# 验证安装
codex --version

# 首次启动，按提示完成认证
codex

认证环节通常涉及浏览器跳转或 API Key 配置。这里有一个与三轴模型直接相关的细节：认证凭据本身也是敏感资产。如果凭据以明文形式存放在工作区可写范围内，而网络又开放，那么凭据就处在泄露路径上。稳妥的做法是把凭据放在工作区之外的用户级配置目录，并确保沙箱的可写范围不覆盖该目录。

本文评述：安装步骤的"简单"是表象。真正需要决策的是"凭据放哪、沙箱覆盖哪、网络开不开"这三个问题的联动。把安装视为纯机械操作，是新手翻车的第一个伏笔。

4.2 第一次改码：一个受控的最小实验

建议第一次使用时不要直接上真实项目，而是构造一个最小实验环境。步骤如下：

第一步，建一个隔离目录。在临时路径下创建一个只含单个文件的小项目，例如一个故意写错一行的 Python 脚本。这样即使模型行为异常，损失也可控。

第二步，以只读沙箱启动。首次运行把沙箱设为只读，观察模型在"不能写"时的行为。它会提出修改方案但无法落地，这正好让你看清它的意图。

第三步，切换到工作区可写 + 逐条确认。再次运行，这次允许写入但每次操作都要确认。重点观察：模型会发起哪些操作？哪些是必要的？哪些超出了你的预期？

第四步，检查 diff。用 /diff 查看改动，确认改动范围与预期一致。

第五步，逐步放宽。当你对模型的行为模式有了把握，再考虑把批准策略从逐条确认放宽到危险确认。

操作原则：权限只应"按需放宽"，不应"默认放宽"。每一次放宽都应有明确的理由，并且可以在出问题时回退。

本文评述：这个五步实验的价值不在于"跑通一次"，而在于建立对模型行为分布的直觉。你知道它在只读时会怎么做、在可写时会怎么做、在需要联网时会怎么做，这些观察构成了后续配置决策的经验基础。跳过这一步直接上生产项目，等于在不知道工具脾气的情况下授权它动你的代码。

4.3 常见翻车点清单

基于社区讨论与文档中反复出现的模式，整理如下清单。每一项都对应三轴模型中的具体取值错误：

翻车点	错误认知	正确做法
在 home 目录启动	"在哪启动都一样"	在项目根目录启动，缩小可写范围
全自动批准图省事	"确认太烦了"	先逐条确认建立直觉，再按需放宽
网络默认开放	"装依赖总得联网"	用白名单限定包源，其余关闭
凭据放在工作区	"方便读取"	放在沙箱可写范围之外
不看 diff 就接受	"模型改的应该没错"	每次改动后用 /diff 复核

5. 决策图：把三轴模型贴到墙上

5.1 决策图的设计逻辑

决策图的目标不是穷举 27 种组合，而是把组合归入少数几个"工作流区域"，每个区域对应一类使用场景。设计逻辑分三层：

第一层，按任务风险分级。把任务分为"探索型"（读代码、理解结构）、"修改型"（改代码、跑测试）、"依赖型"（装包、联网拉取）。风险依次递增。

第二层，为每级任务指定权限基线。探索型用只读沙箱 + 全自动批准（因为只读操作风险低，确认反而拖慢）；修改型用工作区可写 + 危险确认；依赖型用工作区可写 + 逐条确认 + 网络白名单。

第三层，设置升级条件。当任务从一级跳到另一级时，权限必须显式重配，不能沿用上一级的设置。这是决策图最关键的一条规则。

5.2 决策图（文字版）

本文评述：这张图的价值在于它的"禁止区"——最后一行明确划出了轻量沙箱的能力边界。很多讨论把沙箱当成万能防护，但如 3.2 节所述，轻量隔离适合防误操作，不适合防恶意代码。决策图把这条边界显式化，比任何"注意安全"的提醒都有效。

5.3 决策图的使用方法：三个检查点

把图贴到墙上只是形式，真正要落地的是三个检查点：

检查点一：启动前。问自己"这次任务属于哪一级"，据此设定三轴初值。不要沿用上一次的配置，因为上一次的任务可能不同级。

检查点二：任务中途升级时。当模型提出超出当前级别的操作（例如修改型任务中突然要联网），立即暂停，判断是否要升级权限。升级意味着重新配置三轴，而不是简单点"同意"。

检查点三：任务结束后。复核 diff 与执行记录，确认没有越界操作。这一步是审计，也是为下一次配置积累经验。

6. 关键配置矩阵与典型场景对照

6.1 配置矩阵

下表把三轴取值展开为矩阵，标注每种组合的适用场景与风险等级。风险等级为本文基于耦合效应分析的定性评估，非工具官方分级。

本文评述：矩阵中"工作区可写 + 全自动 + 开放"被标为高风险，不是因为它一定会出事，而是因为它的失效模式不可观测。前两轴的错误会报错，第三轴配合全自动时，错误可能静默发生。风险管理的经验法则是：优先控制那些"出错也看不见"的环节。

6.2 典型场景对照：三个真实工作流

场景 A：接手陌生代码库。目标是理解结构而非修改。配置为只读 + 全自动 + 关闭网络。操作路径：用自然语言让模型总结模块职责，用 /diff 确认无改动。此场景下批准策略可以全自动，因为只读操作不产生副作用。

场景 B：修复一个已知 bug。目标是定点修改。配置为工作区可写 + 危险确认 + 关闭网络。操作路径：先让模型定位问题并给出方案，确认方案后再允许写入，最后跑测试验证。危险确认的含义是：读操作自动放行，写操作与命令执行需确认。

场景 C：初始化一个新项目。目标是脚手架搭建，必然涉及联网。配置为工作区可写 + 逐条确认 + 网络白名单。操作路径：预先在配置中列出可信包源，模型发起 npm install 时逐条确认目标包名，安装完成后立即把网络切回关闭。

本文评述：三个场景的差异不在命令，而在权限姿态的切换节奏。场景 C 的关键动作是"用完即关"——网络权限不应长期开放，而应作为临时授权。这一习惯的养成，比记住任何斜杠命令都更能降低风险。

7. 斜杠命令与快捷键的语义分层

7.1 按"作用于哪一轴"重新分类

速查表按字母或功能罗列命令，但更有用的分类方式是按命令作用于三轴的哪一轴。这样分类后，命令与权限模型就接上了。

命令类别	代表命令	作用轴	使用时机
权限调整类	/approvals	批准策略	任务升级、需要放宽或收紧时
审查类	/diff	审计（跨轴）	每次改动后、任务结束前
模型选择类	/model	不直接作用	任务复杂度变化时
会话控制类	中断、清空上下文	不直接作用	模型跑偏、上下文污染时

本文评述：这个分类揭示了一个常被忽略的事实——真正与安全相关的命令只有两类：权限调整类和审查类。模型选择与会话控制影响的是输出质量，不影响权限边界。新手把精力平均分配给所有命令，不如重点掌握这两类。

7.2 快捷键的认知价值：中断与换行

快捷键中最值得单独说的是中断键。在权限模型里，中断是最后一道人工防线：当模型开始执行一个你没预料到的操作链时，中断键是唯一能立即止损的手段。它的价值不在于"方便"，而在于"安全阀"。

换行键（如 Ctrl+J）的价值则在于降低指令歧义。多行输入让你能写出结构清晰的指令，减少模型误解意图的概率。误解越少，越界操作越少——这是快捷键与权限安全的间接关联。

本文评述：把快捷键当"效率工具"是浅层理解，把它当"控制工具"才是深层理解。中断键对应风险控制，换行键对应意图精确，两者都在为权限安全服务。

7.3 一条命令的使用决策树

以最常见的困惑"什么时候该用 /approvals"为例，给出一条决策路径：

本文评述：这条决策树的核心变量是"行为直觉"与"可逆性"，而非任务类型本身。同样的改码任务，在熟悉的项目里可以放宽，在陌生项目里应收紧。这解释了为什么"照抄别人的配置"往往不管用——别人的直觉不等于你的直觉。

8. 对比与局限：与同类工具的横向审视

8.1 同类工具的权限设计谱系

把 Codex CLI 放进更大的谱系里看，Agentic Coding 工具的权限设计大致有三条路线：

路线一，终端原生代理。以 Codex CLI、Claude Code 为代表，直接在用户终端运行，依赖操作系统级沙箱与交互式批准。优点是贴近真实工作流，缺点是与宿主环境耦合紧。

路线二，IDE 内嵌代理。以各类编辑器插件为代表，权限受限于编辑器 API，通常不能任意执行 shell。优点是边界清晰，缺点是能力受限。

路线三，容器化代理。以在隔离容器中运行的方案为代表，权限由容器边界定义。优点是隔离强，缺点是启动开销与文件同步复杂度高。

本文评述：三条路线不是替代关系，而是适用场景的分工。日常改码用路线一，快速原型用路线二，处理不可信代码用路线三。三轴模型的价值在于它是跨路线的——无论用哪种工具，你都可以问"沙箱、批准、网络各是什么取值"。

8.2 三轴模型的局限

任何模型都有边界，三轴模型至少有三处局限需要诚实说明：

局限一，忽略时间维度。三轴描述的是某一时刻的静态配置，但风险往往在时间中累积——一次放宽的授权可能被后续多轮对话继承。模型没有刻画"授权有效期"这一变量。

局限二，忽略模型自身的不确定性。同样的权限配置，不同模型、不同提示词下的行为分布不同。三轴模型假设"配置决定行为边界"，但实际边界还受模型能力影响。

局限三，定性而非定量。矩阵中的风险等级是定性评估，缺乏可量化的风险度量。这与软件安全领域长期存在的"风险难以量化"问题一致（Spring et al., 2021）。

本文评述：承认局限不是削弱模型，而是划定它的适用边界。三轴模型适合做配置决策的思维脚手架，不适合做精确的风险评分。把它当脚手架用，它能显著降低认知负荷；把它当评分卡用，它会给出虚假的精确感。

8.3 与学术研究的衔接

Agentic 工具的权限问题在学术上并非全新。最小权限原则（principle of least privilege）可追溯到 Saltzer 与 Schroeder 1975 年的经典论文，其核心主张——每个主体只应获得完成任务所必需的最小权限——正是三轴模型的理论根基。近年 LLM 代理的安全研究则把这一原则应用到新场景：有工作系统梳理了 LLM 代理在工具调用中的攻击面（Greshake et al., 2023），指出间接提示注入可诱导代理执行非预期操作；也有研究从"能力控制"角度讨论如何限制代理的行为范围（Greenblatt et al., 2024）。

本文评述：这些研究为三轴模型提供了理论支撑，但也提示了一个模型未覆盖的风险——提示注入可以绕过批准策略。如果攻击者能在模型读取的内容（如网页、issue 描述）中植入指令，模型可能发起用户未预期的操作。此时批准策略是最后防线，但若策略设为全自动，防线即失效。这从另一个角度印证了本文的主张：全自动批准只应在低风险、只读场景使用。

9. 团队落地：策略固化与审计

9.1 从个人习惯到团队策略

个人使用可以靠直觉，团队使用必须靠策略。策略固化的第一步是把三轴取值写成可检查的规则，而不是口头提醒。例如：

# 团队权限基线（示例，需按项目调整）
# 规则 1：默认只读，任何写操作需显式升级
# 规则 2：网络默认关闭，装依赖时临时开白名单
# 规则 3：凭据目录不在沙箱可写范围内
# 规则 4：全自动批准仅允许用于只读任务
# 规则 5：每次任务结束必须复核 diff

本文评述：规则的价值在于可审计。口头提醒无法验证是否执行，规则可以对照检查。团队落地的最小可行方案不是买工具，而是把上述五条写进 onboarding 文档，并在 code review 时抽查。

9.2 审计的三个层次

层次一，操作级审计。每次任务后用 /diff 复核改动，确认无越界。这是最低成本、最高频的审计。

层次二，配置级审计。定期检查团队成员的权限配置是否偏离基线。偏离不一定是错，但应有理由。

层次三，事件级审计。当发生越界或泄露时，回溯三轴取值与操作序列，定位是哪一轴失效。这一层次需要保留会话记录。

本文评述：三个层次的成本递增、频率递减，构成一个合理的审计金字塔。多数团队只需做好层次一就能规避大部分风险，层次二是锦上添花，层次三只在事故后启用。

9.3 拓展资源

以下资源适合进一步深入，均在新窗口打开：

· OpenAI Codex CLI 官方仓库与文档：🔒 复制本站文章内容需登录并达到 L3。当前：未登录