Codex 高级配置指南：从安全策略到效率提升

✍ 领哥LingGe🕐 2026-06-19📦 14.1 KB 🟢 已读 𝕏 文章列表

大多数用户仅对 Codex 进行基础配置，导致效率低下且存在安全隐患。本文提出了一套分层配置方案，通过建立全局安全底座及 fast、review、audit 三种工作模式，解决权限失控、成本过高及项目规则混乱等问题，帮助用户在保障安全的前提下最大化开发效率。

Codex 安全配置工作流优化开发工具沙箱权限 AI辅助编程

# 我敢打赌90%人使用Codex不会做这些高级设置。 **作者**: 领哥LingGe **日期**: 2026-06-18T05:22:41.000Z **来源**: [https://x.com/shangdu2005/status/2067478081783357777](https://x.com/shangdu2005/status/2067478081783357777) --- ![Image](/doc/2562/image/img_0269df3f0a78.jpg) 很多人安装 Codex 后，只做了一件事： model = "gpt-5.5" 然后就开始让它读项目、改代码、执行命令。这样当然能用，但用久之后很容易遇到这些问题： - 普通小任务也在用最高推理，速度慢、消耗高 - 复杂重构和安全审查，又没有单独的深度模式 - 从 GitHub 下载的陌生项目，也敢直接让它执行 - 为了临时联网，干脆长期开放网络权限 - 本机的 Token、数据库密码和云服务密钥，可能被传给子进程 - 不同项目的规则混在一起，每次都要重新提醒 Codex 真正好不好用，不只取决于模型。更重要的是，你有没有给它配置好：工作模式、权限边界、项目规则和安全策略。这篇文章不讲一大堆冷门参数，直接给你一套可以复制使用的方案。配置完成后，你将拥有三种工作模式： 1. fast：日常开发 2. review：深度审查 3. audit：陌生项目只读分析 ![Image](/doc/2562/image/img_804e1c184058.jpg) ## 一、先理解 Codex 的三层配置为了方便理解，可以把 Codex 配置分成三层。第一层：全局配置位置： macOS / Linux： ~/.codex/config.toml Windows： %USERPROFILE%\.codex\config.toml 这里放所有项目都要遵守的默认设置，例如： - 默认模型 - 默认推理强度 - 沙箱权限 - 审批方式 - 网络权限 - 环境变量策略它相当于 Codex 的安全底座。第二层：Profile 工作模式例如： ~/.codex/fast.config.toml ~/.codex/review.config.toml ~/.codex/audit.config.toml 不同任务使用不同模式，不需要反复修改主配置文件。使用时直接切换： codex --profile fast codex --profile review codex --profile audit 第三层：项目配置位置：项目目录/.codex/config.toml 这一层只对当前项目生效。例如： - 当前项目是否允许联网 - 修改完成后必须运行哪些测试 - 哪些目录不允许修改 - 是否允许升级依赖 - 当前项目使用什么审查标准这样不同项目之间不会互相影响。 # 二、先搭建一份安全的全局配置打开： ~/.codex/config.toml 写入： ``` # 模型名称按自己账号实际支持情况修改 model = "gpt-5.5" # 默认使用较高推理强度 model_reasoning_effort = "high" # 控制最终输出长度 model_verbosity = "low" # 需要扩大权限时先向用户申请 approval_policy = "on-request" # 可以修改当前工作区，但不能随意操作整台电脑 sandbox_mode = "workspace-write" # 不加载登录 Shell，减少未知启动脚本带来的风险 allow_login_shell = false # 减少终端里过多的推理过程输出 hide_agent_reasoning = true # 文件路径可以直接用 VS Code 打开 file_opener = "vscode" [sandbox_workspace_write] # 默认禁止工具命令访问外网 network_access = false [shell_environment_policy] # 只向子进程传递必要的环境变量 include_only = ["PATH", "HOME"] [history] # 限制本地历史文件最大约 100MB max_bytes = 104857600 [analytics] # 不发送匿名使用统计 enabled = false [tui] # 任务完成或需要授权时提醒 notifications = [ "agent-turn-complete", "approval-requested" ] notification_method = "auto" notification_condition = "unfocused" # 保留终端滚动记录 alternate_screen = "never" ``` 这份配置翻译成人话就是： - Codex 可以正常读取和修改当前项目 - 默认不能随意访问外网 - 需要更高权限时必须先问你 - 不把整台电脑的环境变量全部交给子进程 - 不允许它随意修改工作区外的文件目的不是把 Codex 锁死。而是让它只获得完成任务真正需要的权限。 ![Image](/doc/2562/image/img_67fdb9a9004f.jpg) # 三、建立日常开发模式：fast 创建文件： ~/.codex/fast.config.toml 写入： ``` model = "gpt-5.4" model_reasoning_effort = "medium" model_verbosity = "low" ``` 启动： codex --profile fast 适合处理： - 修复普通报错 - 编写小功能 - 补充单元测试 - 修改页面样式 - 编写常规脚本 - 调整配置文件很多任务根本不需要最高推理强度。把普通任务放到 fast 模式，通常可以获得更快的响应速度。模型名称按自己的账号和客户端实际支持情况替换即可。 # 四、建立深度审查模式：review 创建文件： ~/.codex/review.config.toml 写入： ``` model = "gpt-5.5" model_reasoning_effort = "xhigh" model_verbosity = "medium" ``` 启动： codex --profile review 适合处理： - 大型代码重构 - 安全漏洞审查 - 并发问题分析 - 隐藏 Bug 排查 - 架构设计检查 - 重要代码合并前审查 - 复杂业务逻辑梳理也可以直接执行一次审查任务： codex exec --profile review \ "审查当前项目的最近改动，重点检查安全漏洞、并发风险、异常处理、边界条件和潜在回归问题。先输出问题清单，再给出修改建议。" 如果当前模型不支持 xhigh，将它改为： model_reasoning_effort = "high" # 五、建立陌生项目审计模式：audit 从 GitHub 或其他地方下载陌生项目时，不建议一上来就允许 Codex 修改和执行。创建文件： ~/.codex/audit.config.toml 写入： model = "gpt-5.5" model_reasoning_effort = "high" model_verbosity = "medium" # 只读，不允许直接修改文件 sandbox_mode = "read-only" 启动： codex --profile audit 或者直接让它先分析项目： codex exec --profile audit \ "先不要修改任何文件。分析项目结构、主要功能、依赖风险、安装脚本、启动脚本和可疑命令，并检查是否存在读取本机密钥或上传环境变量的行为。" 在这个模式下，Codex 可以： - 阅读代码 - 分析项目结构 - 查找安全问题 - 检查依赖和脚本 - 给出修改建议但不能直接修改文件。正确顺序应该是：下载项目 ↓ 使用 audit 只读分析 ↓ 检查项目里的配置和脚本 ↓ 确认安全 ↓ 再切换到 fast 或 review 先看清楚，再给权限。 # 六、注意新版 Profile 的写法一些旧教程会让你把 Profile 写在主配置文件中： ``` [profiles.review] model = "gpt-5.5" ``` 新版 Codex 应该为每个 Profile 创建独立文件： ~/.codex/review.config.toml 然后运行： codex --profile review Profile 文件只需要填写与全局配置不同的部分。例如，全局配置已经设置了： ``` approval_policy = "on-request" sandbox_mode = "workspace-write" ``` 那么 fast.config.toml 和 review.config.toml 没有特殊需求时，就不需要重复写。可以简单理解为：全局配置负责打底 Profile 只覆盖发生变化的参数 # 七、给每个项目增加自己的规则在项目中创建：项目目录/.codex/config.toml 例如： ``` model_reasoning_effort = "high" model_verbosity = "low" approval_policy = "on-request" sandbox_mode = "workspace-write" [sandbox_workspace_write] network_access = false ``` 然后在项目根目录创建： AGENTS.md 写入当前项目必须遵守的规则： # 项目开发规则 1. 修改业务代码后必须补充或更新测试。 2. 不允许修改已经执行过的数据库迁移文件。 3. 不允许直接删除旧接口，除非用户明确要求。 4. 新增接口必须检查身份验证和权限控制。 5. 未经允许不得升级主要依赖版本。 6. 修改完成后必须运行 lint、类型检查和单元测试。 7. 不允许读取或提交 .env、私钥和生产凭据。 8. 执行破坏性命令前必须先说明影响。以后进入这个项目时，Codex 就能按照项目自己的规则工作。比每次在对话里重新提醒稳定得多。 # 八、陌生仓库不要急着设为可信陌生项目里最危险的不一定是业务代码。还要重点检查： .codex/config.toml .codex/hooks.json .codex/hooks/ AGENTS.md package.json 安装脚本启动脚本这些文件中可能包含： - 自动执行外部命令 - 下载远程脚本 - 读取本机环境变量 - 修改 Git 配置 - 访问云服务凭据 - 上传 .env - 修改工作区之外的文件 - 连接生产数据库项目级 .codex 配置和项目 Hooks，只有项目被信任后才会加载。因此不要因为一个项目 Star 很多，就直接把本机权限交给它。 # 九、单次临时修改，不要动配置文件有些权限只需要临时开放一次。这种情况下，不要修改长期配置。 ``` 临时切换模型 codex --model gpt-5.4 仅本次允许联网 codex --profile fast \ --config sandbox_workspace_write.network_access=true 临时限制子进程环境变量 codex --config \ 'shell_environment_policy.include_only=["PATH","HOME"]' 临时关闭某个 MCP Server codex --config mcp_servers.context7.enabled=false ``` 需要注意： --config 后面的值使用 TOML 格式，不是 JSON。 Windows PowerShell、CMD、Bash 和 Zsh 对引号的处理不同。同一条命令在不同终端报错时，优先检查引号格式。 # 十、一定要分清沙箱和审批很多人把这两个概念混在一起。实际上：沙箱：决定 Codex 实际上能访问什么。审批：决定 Codex 在什么情况下必须停下来询问你。日常使用推荐： approval_policy = "on-request" sandbox_mode = "workspace-write" 这套组合意味着： - 可以修改当前项目 - 超出已有权限时先申请 - 工作区之外仍然受到限制分析陌生项目时推荐： approval_policy = "on-request" sandbox_mode = "read-only" 最危险的组合是： approval_policy = "never" sandbox_mode = "danger-full-access" 这相当于： - 不需要人工审批 - 没有沙箱边界 - 可以直接执行命令 - 可以访问工作区之外的文件这种配置只适合已经被 Docker、虚拟机或一次性云环境隔离的场景。不要在存放重要文件和密钥的主力电脑上这样配置。 # 十一、环境变量比文件权限更容易被忽略你的终端环境中可能存在： ``` AWS_ACCESS_KEY_ID AZURE_OPENAI_API_KEY GITHUB_TOKEN NPM_TOKEN DATABASE_URL PRIVATE_KEY DEPLOY_TOKEN ``` 当 Codex 启动测试、构建工具或第三方脚本时，这些变量可能会被传递给子进程。因此我在基础配置中使用了： [shell_environment_policy] include_only = ["PATH", "HOME"] 需要其他变量时，再根据项目逐个加入。最危险的组合通常不是单独开放网络，而是：允许访问外网 + 继承全部环境变量 + 执行陌生项目脚本这三件事同时出现时，风险会明显增加。 # 十二、提示词负责提醒，Hooks 负责强制执行你可以在 AGENTS.md 中告诉 Codex： - 不要执行 rm -rf - 不要强制推送 - 不要提交 .env - 不要访问生产数据库但提示词本质上仍然是行为指导。如果某些规则绝对不能被绕过，就应该使用 Hooks，在命令执行前进行确定性检查。例如拦截： rm -rf curl ... | sh wget ... | bash git push --force chmod 777 读取 SSH 私钥上传 .env 连接生产数据库简单规则写进 AGENTS.md。不可绕过的安全规则交给 Hooks。 # 十三、最终推荐的目录结构配置完成后，你的目录大致应该是： ``` ~/.codex/ ├── config.toml ├── fast.config.toml ├── review.config.toml └── audit.config.toml ``` 项目目录： ``` 项目目录/ ├── AGENTS.md └── .codex/ └── config.toml ``` 对应关系： config.toml 负责全局安全底线 fast.config.toml 负责日常开发 review.config.toml 负责复杂任务和深度审查 audit.config.toml 负责陌生项目只读分析项目/.codex/config.toml 负责当前仓库的特殊设置 AGENTS.md 负责项目开发规范 # 十四、日常只需要记住这几条命令 # 普通开发 codex --profile fast # 深度审查 codex --profile review # 陌生项目只读分析 codex --profile audit 临时允许联网： codex --profile fast \ --config sandbox_workspace_write.network_access=true 深度审查当前修改： codex exec --profile review \ "审查当前修改，检查安全、并发、异常处理、边界条件和回归风险。" 陌生项目安全检查： codex exec --profile audit \ "不要修改文件，先检查项目结构、依赖、安装脚本、可疑命令和凭据泄漏风险。" # 十五、配置完成后检查一次 □ Profile 使用独立配置文件 □ 默认网络权限已经关闭 □ 日常开发使用 workspace-write □ 陌生项目使用 read-only □ 配置文件里没有明文 API Key □ 没有把全部敏感环境变量传给子进程 □ 主力电脑没有开启 danger-full-access □ 已检查陌生项目中的 .codex 和 AGENTS.md □ 高风险操作仍然需要审批 □ 不可绕过的安全规则准备使用 Hooks # 最后总结 Codex 的高级配置，不是为了把几十个参数全部研究一遍。真正有价值的只有四件事：简单任务跑得快复杂任务想得深陌生项目先只读危险操作有边界模型决定 Codex 能做到什么。配置决定它能不能长期、安全、稳定地做到。最成熟的使用方式，不是给 Agent 无限权限，而是先规定它可以做什么，再允许它在明确边界内自主完成任务。把 fast、review、audit 三种模式配置好以后，你使用 Codex 的效率、安全性和稳定性，都会比默认状态高出一个档次。建议先收藏，配置时直接对照复制，更简单的方法复制内容扔给AI 。 ## 相关链接 - [领哥LingGe](https://x.com/shangdu2005) - [@shangdu2005](https://x.com/shangdu2005) - [14K](https://x.com/shangdu2005/status/2067478081783357777/analytics) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [1:22 PM · Jun 18, 2026](https://x.com/shangdu2005/status/2067478081783357777) - [14K Views](https://x.com/shangdu2005/status/2067478081783357777/analytics) - [View quotes](https://x.com/shangdu2005/status/2067478081783357777/quotes) --- *导出时间: 2026/6/19 12:35:53*

🔗 相关文档