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 # 检查你的设置结果意味着什么跳到Linux/WSL2 上bwrap为空沙箱起不来于是每条命令都失败进提示修复 1装 bubblewrapapproval_policy untrusted你让 Codex 在每条命令前都问修复 2设 on-requestsandbox_mode read-only编辑按设计被挡触发升级修复 3workspace-write网络命令失败npm、git fetch沙箱挡了出站网络修复 4network_access版本在 0.115–0.121 区间已知的apply_patch回归修复 5锁版本 / 升级macOS只有部分命令提示工作区外的真实写入 / 网络访问修复 6扩宽 roots这篇讲的是运行时的执行和沙箱/审批错误command failed; retry without sandbox提示以及「每条命令都要审批」的死循环。如果你的问题是装完就codex: command not found那是 PATH 问题不是沙箱问题看 codex: command not foundnpm install 的 7 个修复。这篇碰到的全部config.toml键参考 Codex CLI config.toml 深入讲解。这个提示到底是什么沙箱 vs 审批Codex 把你模型的命令放在两个独立的控制项后面跑。人们把这俩搞混而这份混淆就是这提示这么烦人的一半原因。第一个控制是沙箱。它设定一条命令能碰什么的技术边界能往哪些文件写、能不能上网。有三种模式下面是 CLI 接受的精确取值字符串read-onlyCodex 能读文件、能跑不写入的命令workspace-writeCodex 能在当前工作区内读写、跑常规本地命令这是交互式默认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 沙箱与审批错误每条各是什么意思症状最可能的原因在哪咬人每次编辑都command failed; retry without sandbox?没装bwrapLinux/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、WSL2Linux 上最常见的根因是第一行。Codex 文档写得很明白在 Linux 和 WSL2 上你要先装 bubblewrapCodex 用 PATH 上找到的第一个bwrap找不到就退回一个需要非特权用户命名空间的内置 helper。两者都不可用时Codex 会打一条启动警告从那之后每条沙箱命令都失败进 retry 提示。这正是 issue #19162 里报告的行为大约从 0.115.0 开始每次文件编辑都失败而维护者的第一个问题就是问有没有按沙箱前置条件装 bubblewrap。由哪个机制来执行沙箱完全取决于你的平台而这决定了你到底要不要装什么平台沙箱机制需要额外安装吗macOS内置 Seatbelt 框架不用Linuxbubblewrapbwrap或经用户命名空间的内置 helper要装 bubblewrapWSL2UbuntuLinux 沙箱路径跟 Linux 一样要装 bubblewrapWindowsPowerShell原生 Windows 沙箱不用如果你在 macOS 或 Windows PowerShell 上每条命令还是提示原因几乎绝不会是沙箱机制本身跳到修复 2审批策略或修复 5版本回归。「装个什么」这类修复是 Linux 和 WSL2 的故事。怎么修覆盖每种配置的方案修复 1Linux/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.tomlapproval_policy on-request sandbox_mode workspace-write用on-requestCodex 自己跑常规的读、编辑和本地命令只在需要踏出工作区或访问网络时才问。你也能每次运行单独设不碰文件codex --ask-for-approval on-request --sandbox workspace-write简写是-a对应--ask-for-approval、-s对应--sandbox两者都记在 Codex CLI 命令行参考里。修复 3从 read-only 切走让编辑被允许如果sandbox_mode read-onlyCodex 根本不能写于是它想做的任何编辑要么被拒、要么升级成 retry 提示。做正常 coding 工作你要workspace-writesandbox_mode workspace-writeread-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/codexlatest codex --version换版本后用一次微小编辑测一下。如果一个干净版本加 bubblewrap 解决了它那原因是回归不是你的配置。修复 6macOS / 跨平台扩宽可写 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#164070.118.00.117.0 OKapply_patch补丁审批循环Closed#17134无Ubuntu 25.10Ubuntu 25.10 上的 AppArmor / 沙箱Closed#18079无即使 bwrap 写入都能用提示仍有误导Closed#191620.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 对话所以它对接 ofox 只需一个环境变量。你把 Codex 指向 ofox 的 base URL 和 key沙箱和审批设置照上面原样保留路由到你想要的任何模型export OPENAI_BASE_URLhttps://api.ofox.io/v1 export OPENAI_API_KEYyour-ofox-key # 然后照常跑 Codex沙箱/审批配置不变 codex --sandbox workspace-write --ask-for-approval on-request这对沙箱提示毫无改变那是个本地控制。它只是意味着这循环背后的后端由你选。ofox 在https://api.ofox.io/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.io/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-referenceCodex 沙箱概念对应 macOS 上的 Seatbelt、Linux/WSL2 上的 bubblewrap、原生 Windows 沙箱、PATH 上的第一个bwrap加内置 helper 后备2026-06-29 核对https://developers.openai.com/codex/concepts/sandboxingCodex CLI 命令行参考对应--ask-for-approval(-a)、--sandbox(-s)、--full-auto废弃、--dangerously-bypass-approvals-and-sandbox/--yolo2026-06-29 核对https://developers.openai.com/codex/cli/referenceGitHub issue #19162每条命令都「retry without sandbox」0.115.02026-06-29 核对command failed; retry without sandbox for every command in Codex CLI · Issue #19162 · openai/codex · GitHubGitHub issue #164070.118.0apply_patch回归0.117.0 正常2026-06-29 核对Regression in 0.118.0: apply_patch enters patch-approval loop (command failed; retry without sandbox?) while 0.117.0 works · Issue #16407 · openai/codex · GitHubGitHub issue #18079即使 bwrap 和写入都能用提示仍有误导2026-06-29 核对apply_patch edit attempts trigger misleading command failed; retry without sandbox? prompt even when bwrap and filesystem writes work · Issue #18079 · openai/codex · GitHubofox API 目录OpenAI 兼容 base URLhttps://api.ofox.io/v1列了 GPT-5.4 系列和 GPT-5.3 Codex2026-06-29 核对OfoxAI — Unified API Gateway for 100 LLMs | OfoxAI Docs