OpenAI 的 Codex 编程助手能够读取文件、编辑代码仓库、运行命令，并与用户机器上的开发工具进行交互。这些功能使其在长时间工程任务中非常实用，但也意味着其安全性在很大程度上取决于用户设定的权限和沙盒边界。据 AIBase 报道，OpenAI 已调查了少量 Codex 删除...
OpenAI 的 Codex 编码代理能够读取文件、编辑代码仓库、运行命令，并与用户机器上的开发工具进行交互。这些功能使其适用于长期工程工作，但同时也意味着其安全性在很大程度上取决于用户选择的权限和沙箱边界。
AIBase 报道称，OpenAI 已调查了少数 Codex 从用户主目录删除文件的案例。根据该报道，受影响的会话是在启用完全访问权限且无沙箱保护的情况下运行的。
AIBase 报道的具体技术解释涉及临时目录逻辑与 $HOME 环境变量之间的错误交互。OpenAI 尚未发布确认该确切过程的公开事后分析报告。
OpenAI 公开确认的内容更为广泛且依然重要：其官方 Codex 文档警告称，完全访问权限移除了项目目录边界，可能导致意外的破坏性操作，从而造成数据丢失。
因此，直接建议是：除非确实需要不受限制的访问并受到另一层隔离保护，否则应将 Codex 限制在沙箱工作区内。
提供的 AIBase 报告将该问题描述为在特定设置组合下发生：
$HOME 环境变量的错误据称导致用户的主目录被视为删除目标。在 macOS 和 Linux 上，$HOME 通常指向当前用户的主目录。该目录可能包含：
因此，针对错误路径的递归删除可能影响的范围远不止当前活动项目。
OpenAI 当前的 Windows 沙箱文档指出，在完全访问权限下运行 Codex 意味着该代理不再局限于项目目录。它可能执行导致数据丢失的意外破坏性操作。
OpenAI 的权限文档定义了三种内置权限配置文件：
| 权限配置文件 | 文件系统行为 | 适用场景 |
|---|---|---|
:read-only | 本地命令执行保持只读 | 仓库检查、规划和审查 |
:workspace | 允许在活动工作区根目录和系统临时目录内写入 | 常规编码和仓库维护 |
:danger-full-access | 移除本地沙箱限制 | 仅在有意且单独隔离地使用不受限制的访问时 |
官方文档还描述了
以下模式属于高风险：
codex --dangerously-bypass-approvals-and-sandbox
通过别名也可实现相同行为：
codex --yolo
这些命令会同时禁用沙盒和审批提示。此处列出是为了让用户识别并避免这种危险配置，而非推荐使用。
OpenAI 将此模式标注为无沙盒、无审批，并表示不推荐正常使用。
编码代理并非仅仅建议命令。在本地代理模式下，它可以直接执行这些命令。
使用工作区沙盒时，操作系统和 Codex 策略会限制命令的写入范围。错误的命令可能仍会损坏当前项目，但不应随意修改无关目录。
而开启完全访问后，技术边界便不复存在。模型及其 Shell 命令可能能够访问：
这就是为何仅靠提示措辞不足以作为控制手段。告诉代理“只编辑这个文件夹”属于行为指令，而沙盒才是强制执行的边界。
OpenAI 将沙盒与审批视为互补控制措施：
移除这两项控制会构成最高风险配置。
审批提示能在危险操作执行前捕获风险，但无法替代文件系统隔离。
用户可能批准错误的命令。自动审查器也只能评估通过审批系统转发的操作。
OpenAI 文档说明，自动审查会对符合条件的审批请求进行风险分析，包括破坏性操作、凭证访问、数据窃取及持续性安全削弱。
典型的自动审查配置为：
approval_policy = "on-request"
approvals_reviewer = "auto_review"
这可在保留审查层的同时减少审批疲劳。
然而，当 Codex 以绕过审批和沙盒的模式启动时，审查者可能无权限边界可强制实施。
更安全的模式是：
OpenAI 根据工作目录是否受版本控制推荐不同默认设置：
对于常规仓库，显式 CLI 命令为：
codex --sandbox workspace-write --ask-for-approval on-request
如需只检查不编辑文件：
codex --sandbox read-only --ask-for-approval
### 按需审批
这些设置将 Codex 限制在定义的执行边界内，同时允许用户批准特殊操作。
OpenAI 还记录了针对无人值守任务的折中方案。可以在沙箱保持激活状态的同时禁用审批提示：
```bash
codex --sandbox workspace-write --ask-for-approval never
在此模式下，Codex 会在工作区限制范围内尽力执行任务，而不会请求权限越界操作。这比同时禁用审批和沙箱机制要安全得多。
在 ChatGPT 桌面应用、Codex CLI 和 IDE 集成中，具体控制方式略有不同，但原理相同。
在桌面或 IDE 界面中，打开提示词撰写器附近的权限选择器。
选择工作区限制模式或默认沙箱模式，而非完全访问。
选择允许 Codex 仅在活动项目或工作区根目录内写入的模式。
在 CLI 中，使用：
codex --sandbox workspace-write --ask-for-approval on-request
打开陌生仓库时，请先使用：
codex --sandbox read-only --ask-for-approval on-request
让 Codex 先审查代码并提出方案，再授予写入权限。
在 Codex 中，使用状态或权限界面确认哪些目录被视为可写入的工作区根目录。
不要假设编辑器中显示的文件夹是智能体可访问的唯一目录。
对需要额外访问权限的命令，使用按需审批。
为降低工作流摩擦，可考虑自动审查，而非完全取消审批。
更改配置文件可能无法追溯性地限制正在运行的进程。
更改设置后：
config.toml 设置Codex 通过以下路径支持配置：
~/.codex/config.toml
对于已建立的沙箱配置系统，更安全的默认设置为：
approval_policy = "on-request"
sandbox_mode = "workspace-write"
更严格的审查配置为：
approval_policy = "on-request"
sandbox_mode = "read-only"
可在不移除沙箱的情况下添加自动审查：
approval_policy = "on-request"
sandbox_mode = "workspace-write"
approvals_reviewer = "auto_review"
OpenAI 还将权限配置文件记录为较新的测试版配置系统。简单的工作区配置为：
default_permissions = ":workspace"
只读默认配置为：
default_permissions = ":read-only"
配置警告： OpenAI 指出，较新的权限配置文件系统与旧的
sandbox_mode设置不兼容。请仅配置其中一个系统。
其他；切勿将两种方法置于同一活动配置中并期待它们会自动结合。
输入一句想法，We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
.env文件对于测试权限配置文件系统测试版的用户，OpenAI提供了扩展内置工作区边界的自定义策略。
项目编辑配置文件可以在保持工作区可写的同时禁止访问环境文件：
default_permissions = "project-edit"
[permissions.project-edit]
extends = ":workspace"
[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"
[permissions.project-edit.network]
enabled = false
该策略：
.env文件。对于许多本地编码任务，这比授予整个机器的广泛访问权限是更好的起点。
组织可以使用托管需求来防止用户选择不受限制的沙箱模式。
OpenAI展示了类似以下内容的允许列表：
allowed_sandbox_modes = ["read-only", "workspace-write"]
这能阻止完全访问成为托管环境中的可用沙箱选项。
较新的权限配置文件系统也可进行集中限制。管理员可以定义已批准的配置文件，并从允许集合中省略:danger-full-access。
这很有用，因为安全策略不应完全依赖于每个开发者记得选择正确模式。
实用的工作流程能在不暴露整个主机系统的情况下，保持Codex的大部分速度。
从项目目录（而非包含无关项目的主目录或父文件夹）启动Codex。
避免使用宽泛路径，例如：
~
或：
/
作为活动工作区。
OpenAI建议在将工作交给Codex之前，使用功能分支并保持git status清洁。
简单的准备流程是：
git status
git switch -c codex/任务名称
git add -A
git commit -m "Codex任务前的检查点"
根据项目调整分支名称和提交信息。
小型提交便于检查和回滚单个更改。
不要在长时间自主会话结束后才创建第一个可恢复的检查点。
将Codex输出视为拉取请求：
对于大型重构、依赖实验、构建系统更改或清理任务，进一步隔离代理。
选项包括：
OpenAI提供了一个安全的开发容器示例，适用于容器设计为...的情况。
外部隔离边界。
版本控制能保护受追踪的仓库文件，但无法保护计算机上的所有文件。
应使用Codex无法通过同一用户账户或挂载文件系统修改的备份系统。示例包括离线备份、不可变快照或支持版本历史记录的远程备份服务。
当文件刚被删除时，后续写入操作可能会覆盖可恢复的磁盘块。
请采取以下预防措施：
对于受追踪的源代码，请从非破坏性检查开始：
git status
git diff
git log --oneline --all
在确认哪些文件和提交仍然可用之前，请勿运行具有破坏性的Git恢复命令。
AIBase报告指出，OpenAI正在更新完全访问权限的警告内容并加强保护措施，同时准备更详细的事件分析报告。
OpenAI当前的公开文档已明确包含完全访问可能导致数据丢失的警告，同时建议使用沙箱边界、严格例外策略、审批流程、权限配置文件、版本控制检查点及隔离开发环境。
在撰写本文时，尚未有关于$HOME目录删除机制这一确切事件的官方公开事后分析报告。
这意味着用户应依赖当前可用的控制措施，而非等待未来的解释说明：
破坏性行为可能源于多个层面：
因此，安全性不能仅依赖模型准确性。
常规编辑、测试、搜索及本地命令执行通常可在工作区边界内完成。
当任务需要额外访问某个目录或网络目标时，建议添加精确例外，而非暴露整个系统。
自动审阅有助于分类审批请求，但无法使无限制执行变得无害。
沙箱仍是本地最强的控制机制，因为它能在命令本身存在错误时限制其可执行的操作。
我的电脑？
当Codex拥有写入权限时，它可以编辑和删除文件。在工作区模式下，这些操作仅限于已配置的可写根目录；在完全访问模式下，本地沙箱限制被移除，从而增加了错误命令的潜在影响。
$HOME删除漏洞？提供的AIBase报告将该解释归因于OpenAI的调查。OpenAI的公开文档确认了更广泛的完全访问数据丢失风险，但截至2026年7月17日，尚无公开的技术事后分析确认确切的$HOME机制。
当Codex仅需要检查仓库时，请使用:read-only模式。对于常规编码，配合按需批准的:workspace或workspace-write模式在生产效率与安全控制之间提供了实用的平衡。
--yolo使用安全吗？--yolo是绕过批准和沙箱的别名。OpenAI将其描述为无沙箱、无批准的高风险模式，因此它不应在包含重要文件的常规主机上使用。
可以。OpenAI文档指出--ask-for-approval never与沙箱模式兼容。例如，codex --sandbox workspace-write --ask-for-approval never在保持工作区边界的同时避免了交互式批准提示。
不能。Git可以恢复已跟踪并提交的仓库文件，但无法自动保护未跟踪的文件、凭据、个人文档、外部数据库或无关文件夹。对于任何未安全存储在版本控制中的数据，请使用独立的备份方案。
不能。自动审查评估符合条件的批准请求，而沙箱则强制执行文件系统和网络边界。在可能的情况下，应同时保留这两项控制措施，而不是将一项视为另一项的替代。
当容器或虚拟机被特意设计为外部安全边界且不包含敏感挂载数据时，这是合理的。请仔细审查挂载点、凭据、网络访问和主机集成，因为完全访问模式仍可能损坏或泄露该环境内可访问的任何内容。
Agent Approvals and Security：关于沙盒模式、审批策略、自动审核及危险设置的官方指南。
所报告的 Codex 文件删除事件发生在最高风险运行条件下：完全访问且无沙盒边界。AIBase 描述了一起疑似与 $HOME 相关的清理失败事件，而 OpenAI 的公开文档则确认了一个更广泛的事实：无限制访问可能引发意外的破坏性操作和数据丢失。
对于大多数开发者而言，常规代码仓库工作并不需要完全访问权限。工作区受限写入、按需审批、版本控制检查点以及隔离环境，能够在不削弱 Codex 核心编码能力的前提下，提供更安全的运行模式。
在运行无人值守任务时，用户可以在保留工作区沙盒的同时禁用审批提示。这比绕过这两层保护要安全得多。
实用规则很简单：仅授予 Codex 访问所需项目的权限，而非整台机器。
