A resumed Codex thread used your machine's default permissions, and OpenAI merged a fix

A saved Codex thread that resumed from cold built its network proxy from whatever the machine's configured default permissions were, rather than the permissions the thread itself was saved with. OpenAI merged the fix into Codex's main branch on October 12, in a pull request from an OpenAI staff address at 16:01:44 UTC.

OpenAI sets out the problem in the commit's own "Why" text: "Restoring unnamed thread permissions after configuration loading leaves network proxy initialization and permission validation using the configured default. A saved read-only thread should also resume when that default is incompatible with current managed requirements."

So the order of operations was the issue. Permissions were restored after configuration had already loaded, by which point the proxy and the permission check had been set up from the default. The fix applies eligible saved permission profiles during configuration loading instead, before network preparation and final validation, while keeping explicit permission overrides and managed requirements authoritative. It preserves managed deny-read restrictions, and it rejects saved external enforcement or materialised filesystem grants rather than restoring those. Ten files changed, with 147 insertions and 52 deletions, across Codex's configuration loading, session handling and app-server request processing.

A new test resumes a read-only thread on a full-access machine

A second commit landed 39 minutes later, at 16:40:11 UTC, adding 276 lines of regression coverage that only run on Linux. Its header comment states the rule the fix is meant to enforce: "Cold resume must initialize the live proxy from the thread's restored permissions."

What the test does is the scenario itself. It resumes a saved read-only thread after the default permissions have changed to :danger-full-access, then checks that the live network proxy honours the restored grants, asks for approval when a new host comes up, persists the approved rule and reuses it without asking again. It also verifies that proxied requests succeed while direct access stays blocked.

That is the part a Codex user can recognise. A thread saved under read-only permissions is saved that way for a reason, and the machine you come back to it on may not be the machine you left it on. Codex CLI 0.162.0 fixed a different corner of the same problem on October 9, where a ripgrep configuration file could unmask paths the sandbox had denied. That one was about reading files; this one is about reaching the network.

Nothing here is in a shipped release

Both changes exist on main and nowhere else. The newest published Codex is 0.162.1 from October 9, which predates both commits, so no version you can install today contains either. There is no CVE, no advisory and no security bulletin. OpenAI has not called this a vulnerability, and nothing in either commit says anyone was affected or how long the behaviour had been there.

Both commits carry a GitOrigin-RevId, which means they are mirrored out of OpenAI's internal repository rather than written in the public one. For now the change sits on main, and a future Codex release is where it would reach anyone's machine.

Note: Links to online stores in articles can be so-called affiliate links. If you buy through this link, MIXED receives a commission from the provider. For you the price does not change.