Codex命令失败retry without sandbox的6个修复方案2026

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

用 Codex 编辑文件或执行命令时，突然弹出这样一个提示，是不是很让人烦躁？别急，先花30秒跑三个检查，哪个不对，哪个就是你的修复点。

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

结果	意味着什么	跳到
Linux/WSL2 上 bwrap 为空	沙箱起不来，于是每条命令都失败进提示	修复 1（装 bubblewrap）
approval_policy = "untrusted"	你让 Codex 在每条命令前都问	修复 2（设 on-request）
sandbox_mode = "read-only"	编辑按设计被挡，触发升级	修复 3（workspace-write）
网络命令失败（npm、git fetch）	沙箱挡了出站网络	修复 4（network_access）
版本在 0.115–0.121 区间	已知的 apply_patch 回归	修复 5（锁版本 / 升级）
macOS，只有部分命令提示	工作区外的真实写入 / 网络访问	修复 6（扩宽 roots）

这篇讲的是运行时的**执行和沙箱/审批错误**：`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 沙箱文档](https://developers.openai.com/codex/concepts/sandboxing) 把这层关系讲得很直接：沙箱定义技术边界，审批策略决定 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 沙箱与审批错误：每条各是什么意思

症状	最可能的原因	在哪咬人
每次编辑都 command failed; retry without sandbox?	没装 bwrap（Linux/WSL2）；沙箱起不来	Linux、WSL2
同样的提示，但只在 apply_patch 编辑时	版本回归把正常写入误判	0.115–0.121 build
「每条命令都先问」	approval_policy = "untrusted"	所有平台
编辑被悄悄拒绝 / 升级	sandbox_mode = "read-only"	所有平台
npm install / git fetch 在沙箱下失败	workspace-write 里网络被挡	所有平台
往仓库外路径写失败	路径不在 writable_roots 里	macOS、Linux
启动时弹沙箱启动警告	缺 bwrap 或用户命名空间被禁	Linux、WSL2

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

平台	沙箱机制	需要额外安装吗？
macOS	内置 Seatbelt 框架	不用
Linux	bubblewrap（bwrap），或经用户命名空间的内置 helper	要，装 bubblewrap
WSL2（Ubuntu）	Linux 沙箱路径，跟 Linux 一样	要，装 bubblewrap
Windows（PowerShell）	原生 Windows 沙箱	不用

如果你在 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 命令行参考](https://developers.openai.com/codex/cli/reference)里。

修复 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/[emailprotected]

# 或升级到最新再测
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。

Issue	报告版本	症状	状态
#12888	多个	Agent 编辑导致「retry without sandbox?」	Closed
#16407	0.118.0（0.117.0 OK）	apply_patch 补丁审批循环	Closed
#17134	无（Ubuntu 25.10）	Ubuntu 25.10 上的 AppArmor / 沙箱	Closed
#18079	无	即使 bwrap 和写入都能用，提示仍有误导	Closed
#19162	0.115.0	每条命令都「retry without sandbox」	Closed

规律很清楚：大约 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 对话，所以它对接只需一个环境变量。你把 Codex 指向的 base URL 和 key，沙箱和审批设置照上面原样保留，路由到你想要的任何模型：

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

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

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

如果沙箱模型本身就不适配你的工作流，下面是几个现实的选项： - **后端的 Codex。** 保留 Codex 的沙箱和审批控制，把 OpenAI 兼容 base URL 指向 ` 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](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](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](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](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](https://github.com/openai/codex/issues/16407) - GitHub issue #18079，即使 bwrap 和写入都能用提示仍有误导（2026-06-29 核对）：[https://github.com/openai/codex/issues/18079](https://github.com/openai/codex/issues/18079) - API 目录，OpenAI 兼容 base URL ` GPT-5.4 系列和 GPT-5.3 Codex（2026-06-29 核对）： **参考来源** - ofox 文档：模型目录 — https://docs.ofox.io/zh/develop/models