OpenAI 警告 Codex 完全访问权限可能导致数据丢失

引言

OpenAI 的 Codex 编码代理能够读取文件、编辑代码仓库、运行命令，并与用户机器上的开发工具进行交互。这些功能使其适用于长期工程工作，但同时也意味着其安全性在很大程度上取决于用户选择的权限和沙箱边界。

AIBase 报道称，OpenAI 已调查了少数 Codex 从用户主目录删除文件的案例。根据该报道，受影响的会话是在启用完全访问权限且无沙箱保护的情况下运行的。

AIBase 报道的具体技术解释涉及临时目录逻辑与 $HOME 环境变量之间的错误交互。OpenAI 尚未发布确认该确切过程的公开事后分析报告。

OpenAI 公开确认的内容更为广泛且依然重要：其官方 Codex 文档警告称，完全访问权限移除了项目目录边界，可能导致意外的破坏性操作，从而造成数据丢失。

因此，直接建议是：除非确实需要不受限制的访问并受到另一层隔离保护，否则应将 Codex 限制在沙箱工作区内。

所报道的文件删除问题涉及什么

提供的 AIBase 报告将该问题描述为在特定设置组合下发生：

1. Codex 被授予了对本地机器的完全访问权限。
2. 沙箱边界被禁用。
3. 批准或自动审查保护机制未激活。
4. 任务试图创建或使用临时工作目录。
5. 涉及 $HOME 环境变量的错误据称导致用户的主目录被视为删除目标。

在 macOS 和 Linux 上，$HOME 通常指向当前用户的主目录。该目录可能包含：

• 桌面和文档文件夹。
• 源代码仓库。
• SSH 配置和密钥。
• 应用程序设置。
• Shell 配置文件。
• 本地数据库。
• 个人文件。
• 云同步文件夹。

因此，针对错误路径的递归删除可能影响的范围远不止当前活动项目。

OpenAI 官方警告的内容

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 以绕过审批和沙盒的模式启动时，审查者可能无权限边界可强制实施。

更安全的模式是：

1. 保持工作区沙盒启用。
2. 使用按需审批或自动审查。
3. 仅在必要时添加范围狭窄的例外。
4. 避免在宿主机上开放无限制访问。

OpenAI 推荐的默认模式

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 会在工作区限制范围内尽力执行任务，而不会请求权限越界操作。这比同时禁用审批和沙箱机制要安全得多。

如何在 Codex 中禁用完全访问权限

在 ChatGPT 桌面应用、Codex CLI 和 IDE 集成中，具体控制方式略有不同，但原理相同。

第 1 步：打开权限控制

在桌面或 IDE 界面中，打开提示词撰写器附近的权限选择器。

选择工作区限制模式或默认沙箱模式，而非完全访问。

第 2 步：正常编码时使用工作区访问权限

选择允许 Codex 仅在活动项目或工作区根目录内写入的模式。

在 CLI 中，使用：

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

第 3 步：初步审查时使用只读模式

打开陌生仓库时，请先使用：

codex --sandbox read-only --ask-for-approval on-request

让 Codex 先审查代码并提出方案，再授予写入权限。

第 4 步：确认当前边界

在 Codex 中，使用状态或权限界面确认哪些目录被视为可写入的工作区根目录。

不要假设编辑器中显示的文件夹是智能体可访问的唯一目录。

第 5 步：对越界操作保持审批启用

对需要额外访问权限的命令，使用按需审批。

为降低工作流摩擦，可考虑自动审查，而非完全取消审批。

第 6 步：重启现有完全访问会话

更改配置文件可能无法追溯性地限制正在运行的进程。

更改设置后：

1. 停止当前 Codex 会话。
2. 确认配置。
3. 从预期项目目录重启 Codex。
4. 继续操作前重新检查当前权限。

更安全的 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 设置不兼容。请仅配置其中一个系统。

其他；切勿将两种方法置于同一活动配置中并期待它们会自动结合。

示例：限制写入工作区并禁止.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的大部分速度。

1. 在专用仓库中工作

从项目目录（而非包含无关项目的主目录或父文件夹）启动Codex。

避免使用宽泛路径，例如：

~

或：

/

作为活动工作区。

2. 委托前使用版本控制

OpenAI建议在将工作交给Codex之前，使用功能分支并保持git status清洁。

简单的准备流程是：

git status
git switch -c codex/任务名称
git add -A
git commit -m "Codex任务前的检查点"

根据项目调整分支名称和提交信息。

3. 频繁提交

小型提交便于检查和回滚单个更改。

不要在长时间自主会话结束后才创建第一个可恢复的检查点。

4. 审查命令和差异

将Codex输出视为拉取请求：

• 检查其提出的命令。
• 审查文件差异。
• 运行测试。
• 确认修改路径。
• 检查意外删除。
• 记录重要决策。

5. 对风险任务使用工作树或容器

对于大型重构、依赖实验、构建系统更改或清理任务，进一步隔离代理。

选项包括：

• Git工作树。
• 一次性虚拟机。
• 开发容器。
• Docker容器。
• 具有有限权限的临时开发账户。

OpenAI提供了一个安全的开发容器示例，适用于容器设计为...的情况。

外部隔离边界。

6. 将备份存放在Agent无法触及的区域

版本控制能保护受追踪的仓库文件，但无法保护计算机上的所有文件。

应使用Codex无法通过同一用户账户或挂载文件系统修改的备份系统。示例包括离线备份、不可变快照或支持版本历史记录的远程备份服务。

意外删除后的应对措施

当文件刚被删除时，后续写入操作可能会覆盖可恢复的磁盘块。

请采取以下预防措施：

1. 立即停止Codex会话。
2. 停止构建工具、包管理器、同步客户端及其他向受影响磁盘写入数据的进程。
3. 不要在受影响驱动器上重新安装软件。
4. 检查Git历史记录、工作树、编辑器本地历史记录、快照及云端版本历史。
5. 优先从已知完好的备份中恢复数据。
6. 对于不可替代的数据，在尝试重复DIY恢复操作前，请考虑专业数据恢复服务。

对于受追踪的源代码，请从非破坏性检查开始：

git status
git diff
git log --oneline --all

在确认哪些文件和提交仍然可用之前，请勿运行具有破坏性的Git恢复命令。

OpenAI正在改进的内容

AIBase报告指出，OpenAI正在更新完全访问权限的警告内容并加强保护措施，同时准备更详细的事件分析报告。

OpenAI当前的公开文档已明确包含完全访问可能导致数据丢失的警告，同时建议使用沙箱边界、严格例外策略、审批流程、权限配置文件、版本控制检查点及隔离开发环境。

在撰写本文时，尚未有关于$HOME目录删除机制这一确切事件的官方公开事后分析报告。

这意味着用户应依赖当前可用的控制措施，而非等待未来的解释说明：

• 不要默认启用完全访问权限。
• 保持项目边界完整。
• 保留对升级操作的审批权限。
• 使用版本控制和备份。
• 隔离高风险自动化操作。

重要区分

模型错误并非唯一风险

破坏性行为可能源于多个层面：

• 模型选择了不安全命令。
• 变量扩展至意外路径。
• Shell错误解析引号。
• 清理脚本指向错误目录。
• 工具从意外工作目录运行。
• 用户未经检查即批准命令。
• 沙箱被禁用。

因此，安全性不能仅依赖模型准确性。

大多数编码任务无需完全访问权限

常规编辑、测试、搜索及本地命令执行通常可在工作区边界内完成。

当任务需要额外访问某个目录或网络目标时，建议添加精确例外，而非暴露整个系统。

自动审阅减少操作摩擦，但不改变后果

自动审阅有助于分类审批请求，但无法使无限制执行变得无害。

沙箱仍是本地最强的控制机制，因为它能在命令本身存在错误时限制其可执行的操作。

常见问题

Codex能否从

我的电脑？

当Codex拥有写入权限时，它可以编辑和删除文件。在工作区模式下，这些操作仅限于已配置的可写根目录；在完全访问模式下，本地沙箱限制被移除，从而增加了错误命令的潜在影响。

OpenAI是否确认了确切的$HOME删除漏洞？

提供的AIBase报告将该解释归因于OpenAI的调查。OpenAI的公开文档确认了更广泛的完全访问数据丢失风险，但截至2026年7月17日，尚无公开的技术事后分析确认确切的$HOME机制。

最安全的Codex权限模式是什么？

当Codex仅需要检查仓库时，请使用:read-only模式。对于常规编码，配合按需批准的:workspace或workspace-write模式在生产效率与安全控制之间提供了实用的平衡。

--yolo使用安全吗？

--yolo是绕过批准和沙箱的别名。OpenAI将其描述为无沙箱、无批准的高风险模式，因此它不应在包含重要文件的常规主机上使用。

Codex能否在无批准提示的情况下自动运行，同时仍保持沙箱环境？

可以。OpenAI文档指出--ask-for-approval never与沙箱模式兼容。例如，codex --sandbox workspace-write --ask-for-approval never在保持工作区边界的同时避免了交互式批准提示。

Git能保护我免受所有类型的Codex数据丢失吗？

不能。Git可以恢复已跟踪并提交的仓库文件，但无法自动保护未跟踪的文件、凭据、个人文档、外部数据库或无关文件夹。对于任何未安全存储在版本控制中的数据，请使用独立的备份方案。

自动审查能取代沙箱吗？

不能。自动审查评估符合条件的批准请求，而沙箱则强制执行文件系统和网络边界。在可能的情况下，应同时保留这两项控制措施，而不是将一项视为另一项的替代。

我应该在容器内使用完全访问模式吗？

当容器或虚拟机被特意设计为外部安全边界且不包含敏感挂载数据时，这是合理的。请仔细审查挂载点、凭据、网络访问和主机集成，因为完全访问模式仍可能损坏或泄露该环境内可访问的任何内容。

相关工具

• Codex CLI：OpenAI的本地命令行编码代理，用于仓库工作和自动化。
• Codex 权限：只读、工作区和完全访问模式的官方文档。
• Codex 沙箱：解释如何强制执行文件系统和网络边界。
• Codex GitHub仓库：官方开源的Codex CLI仓库。
• Visual Studio Code Dev Containers：在隔离容器环境中运行开发工作流。
• Git：为已跟踪的源文件提供版本历史、分支、差异和回滚功能。

相关链接

Agent Approvals and Security：关于沙盒模式、审批策略、自动审核及危险设置的官方指南。

• Codex Permissions：最小权限配置文件的官方参考。
• Codex Sandboxing：解释跨 Codex 平台的项目边界和沙盒行为。
• Windows Sandbox for Codex：包含 OpenAI 的明确警告：完全访问可能导致破坏性操作和数据丢失。
• Running Codex Safely at OpenAI：描述 OpenAI 内部用于受限执行和审核的控制机制。
• Codex CLI Documentation：官方安装及本地使用说明。
• OpenAI Codex GitHub Repository：源代码、问题报告、安全策略及版本信息。

总结

所报告的 Codex 文件删除事件发生在最高风险运行条件下：完全访问且无沙盒边界。AIBase 描述了一起疑似与 $HOME 相关的清理失败事件，而 OpenAI 的公开文档则确认了一个更广泛的事实：无限制访问可能引发意外的破坏性操作和数据丢失。

对于大多数开发者而言，常规代码仓库工作并不需要完全访问权限。工作区受限写入、按需审批、版本控制检查点以及隔离环境，能够在不削弱 Codex 核心编码能力的前提下，提供更安全的运行模式。

在运行无人值守任务时，用户可以在保留工作区沙盒的同时禁用审批提示。这比绕过这两层保护要安全得多。

实用规则很简单：仅授予 Codex 访问所需项目的权限，而非整台机器。