Codex CLI 0.162.0 stops a ripgrep config from unmasking files its sandbox denied
A configuration file in a developer's own ripgrep setup could stop OpenAI's Codex sandbox masking files it had been told to deny, and Codex CLI 0.162.0 closes it. The Codex changelog entry dated October 8 lists the change as "keep ripgrep configuration from weakening deny-glob masks", alongside three other repairs to the Linux sandbox.
Codex runs shell commands inside a sandbox, and the deny list is how files are kept out of its reach. Image: OpenAI Image: OpenAI
The mechanism is spelled out in the pull request behind it, #51527 in OpenAI's codex repository, merged on October 7. "User ripgrep configuration can suppress the file list used to construct Linux sandbox deny masks," it says. "For example, --quiet in RIPGREP_CONFIG_PATH can leave files matching deny globs unmasked." The fix passes --no-config to the ripgrep call that expands the denied-file globs.
Codex builds that mask by asking ripgrep which files match each deny glob, so a setting that silences ripgrep's output silences the list. The regression test added with the fix feeds the tool a configuration containing --quiet and checks "that denied files remain unreadable and unwritable while allowed files remain accessible".
A writable bwrap on PATH was eligible to run outside the sandbox
The second repair deals with how Codex finds the bubblewrap binary that builds the sandbox in the first place. #51211, merged on October 6, states the weakness in its own terms: "Bubblewrap 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 release now filters canonical PATH candidates against the filesystem policy and the effective user permissions, including writable ancestors, symlinked roots and full-disk write access, and keeps protected system installations while rejecting replaceable paths. It also picks the launcher with the command's own permissions before the proc-mount preflight, and keeps the bundled bubblewrap as a fallback. Its tests cover writable bwrap candidates that "are neither probed nor launched", including when the command runs in a workspace subdirectory or uses managed networking with full-disk write access.
Both cases need something already on the machine
Each one rests on a local precondition. The ripgrep case needs a configuration file the user pointed RIPGREP_CONFIG_PATH at, and the bubblewrap case a writable bwrap binary sitting on PATH ahead of a protected one. The ripgrep test is skipped outright when no protected rg executable is available on the machine running it.
Two more sandbox fixes shipped with them. OpenAI's release notes for 0.162.0 list #50059 as a fix for Linux sandbox startup with multiple denied files, which is the condition the ripgrep test builds on, and #51407 as protection for the ripgrep lookup Codex makes while it constructs the sandbox.
The CLI is the half of Codex that runs on a developer's own machine, which is where the sandbox does its work, as against the cloud side that posts code review comments straight to GitHub.
Windows picked up fixes in the same release
0.162.0 also restores ordinary drive-letter file access on Windows 10 and matches Windows sandbox temp permissions to the child process environment. OpenAI now publishes a signed PowerShell installer with Windows releases, and has fixed archive checksum verification when PowerShell 7 module paths are present, a case where a native launcher stopped Get-FileHash loading and so blocked the check.
The release reached npm as @openai/codex 0.162.0 at 19:01 UTC on October 8, about 27 hours after 0.161.0, with the per-platform builds following over the next ten minutes. OpenAI's own install line for it is npm install -g @openai/[email protected].
