Fixing Linux Sandbox Leaks in Codex CLI 0.162.0

Ethan Park

Let's get straight into the build, and first, thanks to Jellypod to help make this daily show a reality. Today is Codex CLI 0.162.0, which went out on October 8, about 27 hours after 0.161.0. The release notes are long, so we're picking one topic: two fixes to the Linux sandbox. One of them is a ripgrep configuration problem that's simple to explain and simple to check on your own machine.

Maya

Start with the mechanism, because it's the interesting part. On Linux, Codex runs shell commands inside a sandbox built with bubblewrap, the bwrap binary. Part of that sandbox is a deny list. You give Codex deny globs, patterns for files the agent shouldn't touch, and Codex turns those patterns into masks over the actual files. To find which files match, it asks ripgrep. It runs rg against each glob and uses the list that comes back.

Maya

The problem is that ripgrep reads a user config file. If you've set RIPGREP_CONFIG_PATH, ripgrep loads flags from that file on every run, including when Codex calls it. The pull request, number 51527, merged October 7, says it directly: user ripgrep configuration can suppress the file list used to construct Linux sandbox deny masks. Its example is a quiet flag in that config file. Quiet silences ripgrep's output, so the list comes back empty, so nothing gets masked, and files matching your deny globs are left unmasked.

Ethan Park

And that's a failure with no error attached. Nothing crashes. The sandbox starts, the deny list looks configured, and the masks are quietly missing. The fix is small. Codex now passes the no config flag to the ripgrep call that expands those globs, so your dotfiles and your RIPGREP_CONFIG_PATH can't change what that call returns. The regression test feeds the tool a config containing the quiet flag and checks that denied files stay unreadable and unwritable while allowed files stay accessible. That's from the pull request itself, and it was reported in an analysis by Mixed News.

Maya

The second fix is about how Codex finds bwrap in the first place. Pull request 51211, merged October 6, describes it this way: bubblewrap discovery probes executables before confinement. At that point, the only exclusion was the command's current directory. So a bwrap candidate sitting in some other writable directory on your PATH was still eligible to run outside the sandbox.

Maya

Now Codex filters the canonical PATH candidates against the filesystem policy and the effective user permissions. That covers writable ancestors, symlinked roots, and full disk write access. It keeps protected system installations, rejects replaceable paths, and falls back to the bundled bubblewrap. The tests cover writable bwrap candidates that are neither probed nor launched, including when the command runs in a workspace subdirectory.

Ethan Park

Two more sandbox fixes shipped alongside those. One fixes Linux sandbox startup when there are multiple denied files, number 50059. The other, 51407, protects the ripgrep lookup Codex makes while it builds the sandbox. Together that's four repairs in the same area of the release.

Ethan Park

Now how to use this. Upgrade by installing the openai codex package from npm globally, pinned to version 0.162.0. As far as the release notes show, you don't need to change your config, because the no config invocation and the bwrap validation happen inside Codex. Then, if you want to know whether you were in the affected group, run two checks. First, echo RIPGREP_CONFIG_PATH in your shell and see whether it's set, and if it is, look at what flags the file contains. Second, use which to see where bwrap resolves on your PATH, and check whether any directory ahead of your system install is writable by your user.

Maya

Which brings us to the caveats, and they matter, because this isn't a drive by compromise story. Both cases need something already on the machine. The ripgrep case needs a config file you pointed RIPGREP_CONFIG_PATH at, with output suppressing flags in it. The bubblewrap case needs a writable bwrap binary on PATH ahead of a protected one. The Mixed News write up also notes that the ripgrep test is skipped when no protected rg executable is available on the test machine. We haven't seen anything in the sources about this being exploited in the wild, and I'd treat any severity ranking as interpretation. The facts are the mechanisms and the fixes.

Ethan Park

One practical note: if you maintain a shared dev image or a CI runner with a global ripgrep config and a messy PATH, that's the combination worth auditing, whether or not you upgrade today. And upgrading is still the right move, since the fix doesn't depend on your config being clean.

Maya

A few smaller things in the same release. In the agent Command Center, you can now press p to pin a task. Pinned tasks go into a shared Pinned group, when the server supports it. And URLs are now clickable in approval headers, questions, MCP prompts, warnings, banners, and verification prompts, including when the link wraps across lines. If you've ever copied half a URL out of an approval prompt, that one's for you.

Ethan Park

On the transcript side, you can navigate and copy transcript blocks with the slash copy command, use Control Insert to copy a selection, and tune mouse wheel scrolling with tui.mouse_scroll_speed in your config. For Windows users, apply_patch now preserves existing CRLF line endings without any opt in, so patches stop flipping line endings on files that use them. Windows also gets a signed PowerShell installer, restored drive letter file access on Windows 10, and a fix for archive checksum verification when PowerShell 7 module paths were present, which had stopped Get File Hash from loading.

Maya

And one for anyone running against an overloaded backend. Codex now honors the server's Retry After guidance on retryable Responses and WebSocket failures, instead of retrying on its own schedule. That should mean fewer premature failures when the service is under load.

Ethan Park

So the takeaway: upgrade to 0.162.0, check whether you have a ripgrep config set, and check what's writable on your PATH. Those two checks take under a minute. That's the changelog for today.