Codex「command failed; retry without sandbox」：6 个修复方案（2026）

Codex 每条命令都问你要不要「Retry Without Sandbox」？30 秒诊断

你跑 Codex，它想编辑一个文件或跑一条命令，然后你看到这个：

command failed; retry without sandbox?

按顺序跑这三个检查。第一个回来不对的，就是你的修复点。

codex --version              # 记下版本；0.115–0.118 有回归
command -v bwrap             # Linux/WSL2：应该有路径；空 = 沙箱起不来
grep -E 'approval_policy|sandbox_mode' ~/.codex/config.toml   # 检查你的设置

这篇讲的是运行时的执行和沙箱/审批错误：command failed; retry without sandbox 提示，以及「每条命令都要审批」的死循环。如果你的问题是装完就 codex: command not found，那是 PATH 问题，不是沙箱问题，看 codex: command not found？npm install 的 7 个修复。这篇碰到的全部 config.toml 键，参考 Codex CLI config.toml 深入讲解。

这个提示到底是什么（沙箱 vs 审批）

Codex 把你模型的命令放在两个独立的控制项后面跑。人们把这俩搞混，而这份混淆就是这提示这么烦人的一半原因。

第一个控制是沙箱。它设定一条命令能碰什么的技术边界：能往哪些文件写、能不能上网。有三种模式，下面是 CLI 接受的精确取值字符串：

• read-only：Codex 能读文件、能跑不写入的命令
• workspace-write：Codex 能在当前工作区内读写、跑常规本地命令（这是交互式默认）
• danger-full-access：无任何文件系统或网络限制

第二个控制是审批策略。它决定 Codex 何时停下来，在跨过沙箱边界前问你。接受的取值：

• untrusted：跑任何东西前都问
• on-request：模型自己跑常规活，只在需要踏出边界时才问（交互式默认）
• never：从不问；不被允许的就直接失败

官方 Codex 沙箱文档把这层关系讲得很直接：沙箱定义技术边界，审批策略决定 Codex 跨过它们之前必须何时停下来问。两者协同工作。

那 command failed; retry without sandbox? 从哪来？一条命令跑了，沙箱层导致它非零退出，审批策略做出反应，提议在你说「是」之后在沙箱外把同一条命令再跑一遍。这措辞暗示「你的代码需要更多权限」，但命令往往本来好好的。是沙箱本身没起来，或是一个回归把正常编辑误判成了拒绝。

模型想跑一条命令
        │
        ▼
  sandbox_mode 套上边界  ──► 命令干净地跑完 ──► 完成
        │
        ▼ （命令在沙箱下非零退出）
  approval_policy 做出反应
        │
        ▼
  "command failed; retry without sandbox?"  ──► 你批准 ──► 不带沙箱重跑

记住这个分野。下面几乎每个修复要么是「让沙箱能干它的活」，要么是「告诉审批策略别打断常规工作」。

什么时候修配置、什么时候换版本、什么时候直接批准

动手改之前，先想清楚你属于哪一桶。这能省下你去重写一份本来就没问题的配置。

修配置——如果缺 bwrap，或者你的 approval_policy/sandbox_mode 被设得比你想要的更严。这是大多数情况，文章其余部分都在讲它。

换版本——如果你在一个有已知回归的版本上，干净配置加 bubblewrap 还是会让普通编辑触发提示。2026 年好几个 build 带了 apply_patch 回归；锁到一个好的，或升级到它之后的版本。

直接批准、继续干活——如果提示只是偶尔在一条真的访问网络、或往项目外写的命令上出现。那是沙箱在干它的活。批准一次比为了一次性的事重搭整套环境快。

退出规则：如果你每小时只在真实的网络/工作区外命令上看到一两次提示，那不是 bug。批准它，接着干。下面这些修复，是给「每一条命令都来」那种情况的。

Codex 沙箱与审批错误：每条各是什么意思

Linux 上最常见的根因是第一行。Codex 文档写得很明白：在 Linux 和 WSL2 上你要先装 bubblewrap；Codex 用 PATH 上找到的第一个 bwrap，找不到就退回一个需要非特权用户命名空间的内置 helper。两者都不可用时，Codex 会打一条启动警告，从那之后每条沙箱命令都失败进 retry 提示。这正是 issue #19162 里报告的行为：大约从 0.115.0 开始每次文件编辑都失败，而维护者的第一个问题就是问有没有按沙箱前置条件装 bubblewrap。

由哪个机制来执行沙箱，完全取决于你的平台，而这决定了你到底要不要装什么：

如果你在 macOS 或 Windows PowerShell 上，每条命令还是提示，原因几乎绝不会是沙箱机制本身；跳到修复 2（审批策略）或修复 5（版本回归）。「装个什么」这类修复是 Linux 和 WSL2 的故事。

怎么修（覆盖每种配置的方案）

修复 1（Linux/WSL2）：装 bubblewrap

这是 Linux 上「每条命令都要审批」那种情况的修复。workspace-write 沙箱需要 bwrap 来执行它的边界。没有它，命令没法沙箱化运行，于是失败、升级。

# Debian / Ubuntu / WSL2 (Ubuntu)
sudo apt-get update && sudo apt-get install -y bubblewrap

# Fedora
sudo dnf install -y bubblewrap

# Arch
sudo pacman -S bubblewrap

command -v bwrap   # 应该是 /usr/bin/bwrap

装完重启 Codex。启动警告应该消失，编辑也该不再提示。如果 bwrap 装了提示还在，可能你的内核禁了非特权用户命名空间，或者某个 AppArmor profile 挡了 bubblewrap。检查：

cat /proc/sys/kernel/unprivileged_userns_clone   # 应该是 1（或在更新的内核上这文件不存在）

特别是在 Ubuntu 25.10 上（issue #17134），用户撞上了 bwrap 周围的 AppArmor 限制。近期 Ubuntu 版本带了一个 AppArmor 策略，限制非特权用户命名空间，而那正是内置 helper 依赖的东西。如果你在一个加固内核上，可能得给 bubblewrap 放行相应的 AppArmor profile；在普通桌面 Ubuntu 上，上面的 apt-get install 就够了，因为系统 bwrap 被它自己的 profile 放行。优先顺序是：先装系统 bwrap 包（它带一个能用的 profile），只有在包装好了但命名空间创建还失败时，才去碰 AppArmor 设置。

macOS 用户完全跳过这个修复。macOS 用内置 Seatbelt 框架，沙箱不用额外安装就能工作。如果 macOS 运行每条命令都提示，你看的是配置或版本问题，不是缺了沙箱二进制。

修复 2：把 approval_policy 设成 on-request

如果 Codex 在每条命令前都问，而 bwrap 又在，那是你的审批策略太严。untrusted 这个值意思是「跑任何东西前都问」，只有当你想审查每一步时它才对。

编辑 ~/.codex/config.toml：

approval_policy = "on-request"
sandbox_mode   = "workspace-write"

用 on-request，Codex 自己跑常规的读、编辑和本地命令，只在需要踏出工作区或访问网络时才问。你也能每次运行单独设，不碰文件：

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

简写是 -a 对应 --ask-for-approval、-s 对应 --sandbox，两者都记在 Codex CLI 命令行参考里。

修复 3：从 read-only 切走，让编辑被允许

如果 sandbox_mode = "read-only"，Codex 根本不能写，于是它想做的任何编辑要么被拒、要么升级成 retry 提示。做正常 coding 工作你要 workspace-write：

sandbox_mode = "workspace-write"

read-only 在你想让 Codex 分析一个仓库而不改任何东西时有用。一旦你让它改代码，它就是错的模式，而 retry 提示就是那个症状。

修复 4：在不放下沙箱的前提下放行网络

一个常见的过激反应是因为 npm install 或 git fetch 失败就直接跳到 danger-full-access。你不需要这么做。workspace-write 沙箱默认挡出站网络，但你能在沙箱内把它打开：

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

这保留了文件系统边界，同时让 package 安装和 fetch 通过。只有在你确实同时需要不受限的文件系统和网络时才去碰 danger-full-access，而且最好在容器里做。

修复 5：锁到 apply_patch 回归之后的版本

如果 bubblewrap 装了、配置干净，普通编辑还是提示，那你大概在一个带回归的 build 上。这些报告：

Issue #16407 把一个回归定位到 0.118.0，那里 apply_patch 进了一个带 retry 提示的补丁审批循环，而 0.117.0 是好的。Issue #19162 报告这行为大约从 0.115.0 开始，几乎影响每次文件编辑。Issue #18079 形容这提示有误导性：bubblewrap 和文件系统写入都能用，但 apply_patch 还是要求 retry without sandbox。

如果你卡在一个坏版本上，锁到一个已知正常的，或往前走到一个修好的版本：

# 锁到指定版本
npm install -g @openai/[email protected]

# 或升级到最新再测
npm install -g @openai/codex@latest
codex --version

换版本后用一次微小编辑测一下。如果一个干净版本加 bubblewrap 解决了它，那原因是回归，不是你的配置。

修复 6（macOS / 跨平台）：扩宽可写 roots

在 macOS 上沙箱通常开箱就能用，所以你真看到提示时，它往往是一次真实的边界命中：命令想往工作区外写。常见情况是构建工具往你 home 文件夹里的缓存目录写，或一个 monorepo 任务碰到了打开目录之外的同级 package。

把那个路径加进 writable_roots，而不是禁掉沙箱：

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
writable_roots = ["/Users/you/.cache/mytool"]

按配置参考，[sandbox_workspace_write] 表还支持 exclude_slash_tmp 和 exclude_tmpdir_env_var，要是你需要收紧 /tmp 和 $TMPDIR 的处理。

关于 —full-auto 和 —yolo 的一点说明

论坛回答里这俩 flag 老出现，其中一个现在成了陷阱。

--full-auto 是个废弃的兼容性 flag。CLI 参考把它标为废弃，说应该用 --sandbox workspace-write；你用它时 Codex 会打一条警告。如果哪篇老博客告诉你「直接 codex --full-auto」，把这个习惯更新成 --sandbox workspace-write --ask-for-approval on-request，它对两个控制项都讲得明明白白。

--dangerously-bypass-approvals-and-sandbox（别名 --yolo）一次去掉两个控制项。它只在一个一次性、网络隔离的容器或 VM 里才是对的工具，因为 Codex 届时能用你的完整权限跑任何命令。对一台你在意的机器做无人值守运行，更安全的组合是：

codex --sandbox workspace-write --ask-for-approval never

它保留文件系统边界，又不为审批停下，这通常才是人们伸手去够 --yolo 时真正想要的。

2026 年的 Codex 沙箱问题：真实报告

下面是这提示背后的公开 issue，连带版本和状态。写本文时它们全都 CLOSED，意味着修复或绕法已落地，但版本号告诉你该避开哪些 build。

规律很清楚：大约 0.115 到 0.118 之间有一簇回归，apply_patch 路径过度触发提示，叠在常青的 Linux 根因（没装 bubblewrap）之上。如果只读一个，#19162 是那条经典的「每条命令」报告，维护者的回复直接指向沙箱前置条件。

怎么确认你的沙箱是健康的

应用一个修复后，去验证，别猜。一个快速循环：

codex --version                         # 脱离回归区间
command -v bwrap                        # Linux：解析到一个路径
grep -E 'approval_policy|sandbox_mode' ~/.codex/config.toml

然后启动 Codex，盯着有没有沙箱启动警告。没有警告，再加一次不弹提示就生效的微小编辑，就说明边界在工作。如果你想让 Codex 自己报出它对环境的看法，近期 build 里带了一个 codex doctor 风格的诊断；跑 codex --help 看你这个版本暴露了哪些子命令，因为它们在各版本之间会变。

一旦你有了能用的配置，一个实用做法是：把它存成一个具名 profile，省得反复敲 flag。配置参考说 profile 文件跟 config.toml 放一起，叫 $CODEX_HOME/profile-name.config.toml，用 --profile profile-name 来选一个。在 config.toml 里留一个严格的默认，给你已经信任的仓库留一个更宽松的 profile 文件：

# ~/.codex/trusted.config.toml
approval_policy = "never"
sandbox_mode   = "workspace-write"

用 codex --profile trusted 启动它。这让你日常运行保持安全，又给信任的仓库一个一 flag 逃生口，全程都不用伸手去够 --yolo。

当沙箱是错的那一层：绕开一个不靠谱的模型步骤

多数 retry-without-sandbox 情况是本地的：bubblewrap、配置，或一个版本回归。但有时底层命令好好的，而模型才是这循环里慢或失败的那部分，你想在同一个 Codex 工作流后面换一个更快或更便宜的后端。

Codex CLI 能跟任何 OpenAI 兼容 endpoint 对话，所以它对接 ofox 只需一个环境变量。你把 Codex 指向 ofox 的 base URL 和 key，沙箱和审批设置照上面原样保留，路由到你想要的任何模型：

export OPENAI_BASE_URL="https://api.ofox.ai/v1"
export OPENAI_API_KEY="your-ofox-key"
# 然后照常跑 Codex；沙箱/审批配置不变
codex --sandbox workspace-write --ask-for-approval on-request

这对沙箱提示毫无改变；那是个本地控制。它只是意味着这循环背后的后端由你选。ofox 在 https://api.ofox.ai/v1 暴露一个 OpenAI 兼容 API，列了 OpenAI 模型（GPT-5.4 系列和 GPT-5.3 Codex）以及其他模型，所以你能保留 Codex 的本地安全控制，独立地换模型。完整的 provider 配置，Codex CLI API 配置指南走了一遍 base URL、key 和模型选择。

想换一种执行模型时的替代方案

如果沙箱模型本身就不适配你的工作流，下面是几个现实的选项：

• ofox 后端的 Codex。 保留 Codex 的沙箱和审批控制，把 OpenAI 兼容 base URL 指向 https://api.ofox.ai/v1，挑你的模型。适合喜欢 Codex 的 UX 但想要后端灵活性的人。配置就一个环境变量。
• --sandbox workspace-write --ask-for-approval never。 同一个 Codex，无提示，文件系统边界完好。适合在你信任的机器上做无人值守的本地运行。
• 一次性容器加 --yolo。 在一个隔离的 VM 或容器里完全绕过。适合那种主机上没有任何东西会被伤到的一次性环境。
• 别的 agentic CLI。 Claude Code 和 Cursor 有它们自己的权限模型。如果你天天跟 Codex 沙箱较劲，另一个工具的默认值也许更合你。在 Claude Code vs Codex CLI vs Cursor里对比它们。

对大多数人，诚实的默认是头两个选项：保留沙箱，修根因，只在有意为之时才放松控制。

FAQ

页面上方的问题对应这提示周围最常见的搜索。完整集合在本页的 FAQ schema 里；短版本是：在 Linux 上，装 bubblewrap；任何平台都设 approval_policy = "on-request" 和 sandbox_mode = "workspace-write"；如果两者都对，怀疑 0.115–0.118 区间的版本回归，锁到一个已知正常的 build。

本次更新核对过的信息源

• Codex 配置参考，对应 approval_policy、sandbox_mode 和 [sandbox_workspace_write] 键与取值（2026-06-29 核对）：https://developers.openai.com/codex/config-reference
• Codex 沙箱概念，对应 macOS 上的 Seatbelt、Linux/WSL2 上的 bubblewrap、原生 Windows 沙箱、PATH 上的第一个 bwrap 加内置 helper 后备（2026-06-29 核对）：https://developers.openai.com/codex/concepts/sandboxing
• Codex CLI 命令行参考，对应 --ask-for-approval (-a)、--sandbox (-s)、--full-auto（废弃）、--dangerously-bypass-approvals-and-sandbox / --yolo（2026-06-29 核对）：https://developers.openai.com/codex/cli/reference
• GitHub issue #19162，每条命令都「retry without sandbox」，0.115.0+（2026-06-29 核对）：https://github.com/openai/codex/issues/19162
• GitHub issue #16407，0.118.0 apply_patch 回归，0.117.0 正常（2026-06-29 核对）：https://github.com/openai/codex/issues/16407
• GitHub issue #18079，即使 bwrap 和写入都能用提示仍有误导（2026-06-29 核对）：https://github.com/openai/codex/issues/18079
• ofox API 目录，OpenAI 兼容 base URL https://api.ofox.ai/v1，列了 GPT-5.4 系列和 GPT-5.3 Codex（2026-06-29 核对）：https://ofox.ai/docs