Codex CLI 0.162.0 Hardens Linux Sandbox and Fixes Windows PowerShell Issues

What changed in the ripgrep deny-glob path​

Codex runs shell commands inside a sandbox, and the deny list is how files are kept out of its reach. On Linux, that list is turned into masks by asking ripgrep which files match each deny glob. The Codex Linux sandbox README describes the flow: Codex builds the mask by asking ripgrep which files match each deny glob, so a setting that silences ripgrep's output silences the list. The README's preferred scan is rg --files --hidden --no-ignore --glob, with an internal globset walker as the fallback when rg isn't installed.

The weak point is that ripgrep reads user configuration. Per ripgrep's own guide, it doesn't look in any predetermined directory for a config file. You have to point the RIPGREP_CONFIG_PATH environment variable at one. The same guide says --no-config always prevents ripgrep from reading configuration from the environment.

Pull request #51527 (merged October 7) explains the problem. "User ripgrep configuration can suppress the file list used to construct Linux sandbox deny masks," and "--quiet" in RIPGREP_CONFIG_PATH "can leave files matching deny globs unmasked." The fix is to pass --no-config to the ripgrep call that expands the denied-file globs.

The regression test extends the existing multiple-denied-files test. It adds a ripgrep configuration containing --quiet and checks that denied files stay unreadable and unwritable while allowed files stay accessible. The ripgrep-specific case is skipped when no protected rg executable is available.

The bubblewrap discovery fix​

Bubblewrap (bwrap) is the helper that actually builds the Linux sandbox. The README says Codex prefers the first bwrap found on PATH outside the current working directory. If none is found, it falls back to a bundled copy.

Pull request #51211 (merged October 6) says the problem is that discovery probes executables before confinement. Excluding only the command's current directory leaves candidates in other writable roots eligible to run outside the sandbox. The PR's fix is to:

• Filter canonical PATH candidates against the filesystem policy and effective user permissions. That covers writable ancestors, symlinked roots and full-disk write access.
• Keep protected system installations and reject replaceable paths.
• Pick the launcher with the command's own permissions before the proc-mount preflight, and keep the bundled bubblewrap fallback.
• Use the effective permission profile and policy working directory for startup warning probes.

The tests add unit coverage for writable roots, symlinks, read-only carveouts, replaceable parents and full-disk policies. Linux integration tests show writable bwrap candidates are neither probed nor launched. That includes runs from a workspace subdirectory and managed networking with full-disk write access.

How much should you worry?​

Not much, but the fixes are worth taking. Both issues depend on local conditions:

• The ripgrep case needs a ripgrep config that someone pointed RIPGREP_CONFIG_PATH at, with options that suppress output.
• The bubblewrap case needs a writable bwrap sitting on PATH ahead of a protected one.

Nothing in the release notes or pull requests reports exploitation in the wild, a remote attack, or a general bypass of every install. Treat this as hardening of the sandbox's own construction logic. Plenty of developers set a ripgrep config for harmless reasons, such as colours, smart-case or --hidden. The lesson is that any security-sensitive internal call to a configurable tool should ignore user config.

The release notes group four Linux sandbox items together: #50059 (startup with multiple denied files), #51211, #51407 (protecting the ripgrep lookup during sandbox construction) and #51527. They are listed as related bug fixes, not as one vulnerability.

One related operational note comes from a downstream issue report. It says Codex 0.160.1 gave up on the first directory ripgrep couldn't list while expanding deny globs. In that report, the generated profile stopped every command on Linux. That is a third-party report about an older build, not something the 0.162.0 notes claim to address, so test your own deny-glob profiles after upgrading.

Windows-side fixes in the same release​

The 0.162.0 release notes also list these Windows changes:

• Ordinary drive-letter file access is restored on Windows 10 (#51511).
• Windows sandbox temp permissions now match the child process environment (#51512).
• Archive checksum verification is fixed when installing through Windows PowerShell with PowerShell 7 module paths present (#51257).
• A signed PowerShell installer is now published with Windows releases (#51158).

A third-party troubleshooting guide notes that Codex uses a native sandbox in PowerShell. In WSL2 it uses the Linux implementation, which needs bubblewrap installed inside the distribution. So the Linux sandbox fixes also apply to Windows developers working in WSL2. That is a general point about how Codex is built, not something the release notes state.

What to do​

1. Check your version with codex --version. Anything older than 0.162.0 lacks these fixes.
2. Upgrade using the method you installed with. For npm, the package is @openai/codex, and 0.162.0 is the version to target.
3. On Linux or WSL2, run command -v bwrap and confirm it resolves to a root-owned, non-writable system path.
4. If you use a ripgrep config, you don't need to remove it. The fix makes Codex ignore it for deny-glob expansion.
5. After upgrading, confirm a file matched by a deny glob really is inaccessible from inside a Codex session. This is a sensible sanity check on my part, not an official step.

The upgrade is routine, and the release notes don't describe any workaround for older builds.