Codex told your DNS server the names of the hosts its proxy then blocked
Codex’s network proxy was resolving a hostname before it checked whether that host was allowed, so the name went out to whoever runs your DNS even when the proxy then refused the connection. OpenAI’s changelog says Codex CLI 0.163.0, published on October 15, “now checks permission before a DNS lookup, rejects duplicate Host headers, and prevents credential aliases from bypassing inspection hooks”.
Codex CLI 0.163.0 was published on October 15. Image: OpenAI Image: OpenAI
The merged pull request is blunter about what that meant. “Resolving unapproved hostnames discloses them to DNS even when the proxy ultimately rejects the request. Allowing local binding in a managed macOS sandbox also granted direct outbound access to port 53,” the pull request says. It merged at 11:10 UTC on October 7, eight days before it reached a release.
Running Codex in a sandbox is how you stop an agent reaching a host. The name of the host it was told not to reach was still leaving the machine.
The managed macOS sandbox left port 53 open
Codex’s macOS sandbox is built on Seatbelt, and in a managed sandbox the rule that let the proxy bind locally also allowed outbound traffic on port 53, the port DNS uses. The fix removes the Seatbelt allowance for external DNS while keeping local binding and loopback proxy access, and adds a Seatbelt child test that external UDP and TCP port 53 access is denied while the proxy still connects.
The same change rechecks baseline restrictions after a local or remote policy approval, so approving a host cannot override an explicit deny or the limits on local and private addresses. It also keeps DNS checks on inner HTTPS requests after an approved CONNECT, including hosts with no stored allowlist entry.
The scope is narrower than it may read. OpenAI publishes no CVE, no severity rating and no statement that anyone was affected, the macOS finding is scoped to a managed sandbox in the pull request’s own words, and what left the machine was the hostname inside a DNS query.
Duplicate Host headers now return a 400
A second fix in the same release closes a disagreement between two parsers. “Policy evaluation and upstream parsers must not select different Host field lines from the same request,” says that pull request, which merged at 23:46 UTC on October 12.
Codex now returns 400 Bad Request for multiple Host headers, identical ones included, before policy evaluation, upstream forwarding or Unix socket routing, on plain HTTP requests and on CONNECT.
A third proxy fix rides along in the same line of the changelog. Codex hands an agent a dummy credential and has the proxy swap in the real one, and a pull request merged on October 9 says a credential bound to a host with inspection hooks “could also be used at an alias without hooks, allowing the proxy to inject the real credential without enforcing hook policy”. Those requests now get a 403 carrying the reason blocked-by-mitm-hook.
A week earlier, 0.162.0 stopped a ripgrep config from unmasking files its sandbox had denied, which was a filesystem problem rather than a network one.
Version 0.163.0 also ships the fix for a resumed Codex thread falling back to the machine’s default permissions, which until now sat on Codex’s main branch with no release behind it. Resuming a saved thread now restores its permissions and network approvals while respecting explicit overrides and current managed policy, according to the same changelog entry. The release installs as @openai/[email protected].
