环境说明宿主机Windows 11虚拟机VMware Virtual Platform操作系统Ubuntu (虚拟机内)工具OpenAI Codex CLI (v0.142.3)一、问题现象在 Linux 虚拟机中安装并运行 OpenAI Codex CLI 时终端弹出以下警告信息虽然程序没有直接崩溃但沙箱功能未能正常初始化virtual-machineVMware-Virtual-Platform:~/NetSentry$ codex ⚠ Codexs Linux sandbox uses bubblewrap and needs access to create user namespaces. ╭──────────────────────────────────────────────╮ │ _ OpenAI Codex (v0.142.3) │ ...同时如果在后台使用ps aux | grep bwrap查看进程会发现根本没有bwrap相关进程在运行这说明 Codex 的安全沙箱并没有成功启动。二、原因分析Codex CLI 在 Linux 系统上默认使用bubblewrap(bwrap) 来创建沙箱以隔离文件系统和网络防止 AI 生成的代码意外破坏系统或泄露数据。bubblewrap的核心机制是利用 Linux 内核的用户命名空间允许无特权用户在隔离环境中拥有“伪 root”权限。出现上述警告通常是因为系统未启用非特权用户命名空间许多 Linux 发行版出于安全考虑默认禁用了此功能。AppArmor 安全模块拦截特别是在 Ubuntu 23.10 及更高版本中即使内核允许创建用户命名空间AppArmor 依然会拦截bwrap的网络等高级权限。三、排查与解决步骤步骤 1确认 bubblewrap 已安装首先检查系统是否安装了bubblewrap并且在环境变量中which bwrap || echo bwrap not in PATH输出结果/usr/bin/bwrap*结论bwrap 已正常安装问题出在权限限制上。*步骤 2启用内核参数允许用户命名空间修改内核参数允许非特权用户创建命名空间。临时生效重启后失效sudo sysctl -w kernel.unprivileged_userns_clone1永久生效echo kernel.unprivileged_userns_clone1 | sudo tee /etc/sysctl.d/99-userns.conf sudo sysctl -p /etc/sysctl.d/99-userns.conf步骤 3测试 Bubblewrap 沙箱是否生效执行完上述操作后运行以下无害的测试命令检查bwrap是否能真正创建沙箱bwrap --ro-bind /usr /usr --ro-bind /lib /lib --ro-bind /lib64 /lib64 --unshare-all echo Sandbox works!遇到新报错bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted分析这个错误非常关键。它说明bwrap尝试创建网络命名空间时失败了。这通常是因为系统底层的 AppArmor 依然在拦截网络权限。步骤 4解除 AppArmor 对用户命名空间的限制核心解决方案针对上述Operation not permitted错误我们需要关闭 AppArmor 对非特权用户命名空间的限制。临时关闭测试sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns0再次运行测试命令bwrap --ro-bind /usr /usr --ro-bind /lib /lib --ro-bind /lib64 /lib64 --unshare-all echo Sandbox works!输出Sandbox works!说明系统层面的沙箱机制已经完全畅通永久关闭限制为了在系统重启后依然生效将其写入配置文件echo kernel.apparmor_restrict_unprivileged_userns0 | sudo tee /etc/sysctl.d/60-apparmor-namespace.conf sudo sysctl -p /etc/sysctl.d/60-apparmor-namespace.conf此时重新启动codex之前的黄色警告就会消失沙箱功能正常工作。四、备用方案直接禁用沙箱适合虚拟机环境如果你是在 VMware 虚拟机中进行开发测试虚拟机本身已经提供了一层物理隔离。如果你不想修改系统的安全策略可以直接让 Codex 在无沙箱模式下运行。方法 1启动时指定参数codex --sandbox danger-full-access方法 2修改配置文件设为默认打开或创建 Codex 的配置文件nano ~/.codex/config.toml添加以下内容sandbox_mode danger-full-access保存退出后直接输入codex即可正常运行。⚠️ 注意danger-full-access模式会让 Codex 拥有当前用户的完整权限可以读写任何文件、执行任何命令。请仅在你完全了解风险并在隔离环境中使用此选项。五、总结在使用 OpenAI Codex CLI 等 AI 辅助编程工具时由于它们需要执行代码Linux 系统的安全机制如 AppArmor、用户命名空间限制经常会发生拦截。遇到类似bubblewrap权限问题核心排查路径为检查工具是否安装 (which bwrap)。检查内核参数 (unprivileged_userns_clone)。检查 AppArmor 限制 (apparmor_restrict_unprivileged_userns)。根据实际环境选择放开限制或禁用沙箱。希望这篇博客能帮到遇到同样问题的开发者如果有其他疑问欢迎在评论区交流。
解决 OpenAI Codex CLI 在 Linux/VMware 中报错:bubblewrap needs access to create user namespaces
发布时间:2026/6/30 4:13:02
环境说明宿主机Windows 11虚拟机VMware Virtual Platform操作系统Ubuntu (虚拟机内)工具OpenAI Codex CLI (v0.142.3)一、问题现象在 Linux 虚拟机中安装并运行 OpenAI Codex CLI 时终端弹出以下警告信息虽然程序没有直接崩溃但沙箱功能未能正常初始化virtual-machineVMware-Virtual-Platform:~/NetSentry$ codex ⚠ Codexs Linux sandbox uses bubblewrap and needs access to create user namespaces. ╭──────────────────────────────────────────────╮ │ _ OpenAI Codex (v0.142.3) │ ...同时如果在后台使用ps aux | grep bwrap查看进程会发现根本没有bwrap相关进程在运行这说明 Codex 的安全沙箱并没有成功启动。二、原因分析Codex CLI 在 Linux 系统上默认使用bubblewrap(bwrap) 来创建沙箱以隔离文件系统和网络防止 AI 生成的代码意外破坏系统或泄露数据。bubblewrap的核心机制是利用 Linux 内核的用户命名空间允许无特权用户在隔离环境中拥有“伪 root”权限。出现上述警告通常是因为系统未启用非特权用户命名空间许多 Linux 发行版出于安全考虑默认禁用了此功能。AppArmor 安全模块拦截特别是在 Ubuntu 23.10 及更高版本中即使内核允许创建用户命名空间AppArmor 依然会拦截bwrap的网络等高级权限。三、排查与解决步骤步骤 1确认 bubblewrap 已安装首先检查系统是否安装了bubblewrap并且在环境变量中which bwrap || echo bwrap not in PATH输出结果/usr/bin/bwrap*结论bwrap 已正常安装问题出在权限限制上。*步骤 2启用内核参数允许用户命名空间修改内核参数允许非特权用户创建命名空间。临时生效重启后失效sudo sysctl -w kernel.unprivileged_userns_clone1永久生效echo kernel.unprivileged_userns_clone1 | sudo tee /etc/sysctl.d/99-userns.conf sudo sysctl -p /etc/sysctl.d/99-userns.conf步骤 3测试 Bubblewrap 沙箱是否生效执行完上述操作后运行以下无害的测试命令检查bwrap是否能真正创建沙箱bwrap --ro-bind /usr /usr --ro-bind /lib /lib --ro-bind /lib64 /lib64 --unshare-all echo Sandbox works!遇到新报错bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted分析这个错误非常关键。它说明bwrap尝试创建网络命名空间时失败了。这通常是因为系统底层的 AppArmor 依然在拦截网络权限。步骤 4解除 AppArmor 对用户命名空间的限制核心解决方案针对上述Operation not permitted错误我们需要关闭 AppArmor 对非特权用户命名空间的限制。临时关闭测试sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns0再次运行测试命令bwrap --ro-bind /usr /usr --ro-bind /lib /lib --ro-bind /lib64 /lib64 --unshare-all echo Sandbox works!输出Sandbox works!说明系统层面的沙箱机制已经完全畅通永久关闭限制为了在系统重启后依然生效将其写入配置文件echo kernel.apparmor_restrict_unprivileged_userns0 | sudo tee /etc/sysctl.d/60-apparmor-namespace.conf sudo sysctl -p /etc/sysctl.d/60-apparmor-namespace.conf此时重新启动codex之前的黄色警告就会消失沙箱功能正常工作。四、备用方案直接禁用沙箱适合虚拟机环境如果你是在 VMware 虚拟机中进行开发测试虚拟机本身已经提供了一层物理隔离。如果你不想修改系统的安全策略可以直接让 Codex 在无沙箱模式下运行。方法 1启动时指定参数codex --sandbox danger-full-access方法 2修改配置文件设为默认打开或创建 Codex 的配置文件nano ~/.codex/config.toml添加以下内容sandbox_mode danger-full-access保存退出后直接输入codex即可正常运行。⚠️ 注意danger-full-access模式会让 Codex 拥有当前用户的完整权限可以读写任何文件、执行任何命令。请仅在你完全了解风险并在隔离环境中使用此选项。五、总结在使用 OpenAI Codex CLI 等 AI 辅助编程工具时由于它们需要执行代码Linux 系统的安全机制如 AppArmor、用户命名空间限制经常会发生拦截。遇到类似bubblewrap权限问题核心排查路径为检查工具是否安装 (which bwrap)。检查内核参数 (unprivileged_userns_clone)。检查 AppArmor 限制 (apparmor_restrict_unprivileged_userns)。根据实际环境选择放开限制或禁用沙箱。希望这篇博客能帮到遇到同样问题的开发者如果有其他疑问欢迎在评论区交流。