MIXED berichtete, Codex CLI 0.163.0 sei am 15. Oktober 2026 veröffentlicht worden. Für die DNS-Adressprüfung beschreibt der OpenAI-Pull-Request #51650 eine neue Reihenfolge: Erst muss eine Allowlist den Host zulassen oder eine Richtlinie die Anfrage freigeben, dann löst der Proxy den Hostnamen auf. Zuvor konnte der angefragte Hostname bereits beim DNS-Resolver landen, obwohl der Proxy die Verbindung anschließend ablehnte.
Die DNS-Abfrage gab dabei den Hostnamen preis. Der Pull-Request beschreibt keine Offenlegung des übrigen Anfrageinhalts oder von Zugangsdaten durch diesen Ablauf.
DNS-Freigabe und der verwaltete macOS-Sandbox-Fall
Der Pull-Request #51650 behandelt außerdem eine eng umrissene Konfiguration: In einer verwalteten macOS-Sandbox mit Seatbelt konnte die Erlaubnis, lokal Verbindungen zu binden, auch ausgehenden Verkehr zum DNS-Port 53 zulassen. Die Änderung nimmt die Freigabe für externes DNS zurück, lässt lokales Binden und den Zugriff auf den Loopback-Proxy aber bestehen.
Nach einer lokalen oder entfernten Richtlinienfreigabe prüft der Proxy weiterhin die grundlegenden Beschränkungen. Eine Genehmigung hebt also etwa Sperren für lokale oder private Adressen nicht auf. DNS-Prüfungen für HTTPS-Anfragen innerhalb eines genehmigten CONNECT-Tunnels bleiben ebenfalls erhalten – auch wenn der Zielhost nicht dauerhaft auf der Allowlist steht.
Der Pull-Request beschreibt Regressionstests, die bei nicht genehmigten Hosts null DNS-Abfragen und in einem Seatbelt-Kindprozess die Sperre für externes UDP und TCP auf Port 53 prüfen. Der lokale Proxy-Zugriff bleibt dabei Teil des Tests.
Zwei weitere Kontrollen für Proxy-Anfragen
Die Pull-Requests #53506 und #52661 beschreiben zwei getrennte Fälle: mehrfache Host-Header und die Nutzung vermittelter Zugangsdaten über einen ungeschützten Alias.
| Proxy-Fall | Bedingung | Reaktion des Proxys |
| DNS-Adressprüfung | Ein Host muss zunächst auf der Allowlist stehen oder per Richtlinie freigegeben sein. | Der Proxy löst den Hostnamen erst danach für die Adressprüfung auf. |
| Mehrere Host-Header | Eine Anfrage enthält mehr als einen Host-Header – auch dann, wenn die Werte identisch sind. | HTTP 400, bevor Richtlinienprüfung, Weiterleitung oder Unix-Socket-Routing beginnen. |
| Alias für vermittelte Zugangsdaten | Ausgewählte Zugangsdaten sind an einen Host mit MITM-Inspektions-Hook gebunden, werden aber über einen Alias ohne diesen Hook angefragt. | HTTP 403 mit blocked-by-mitm-hook. |
Der Schutz gegen mehrfache Host-Header gilt laut Pull-Request für einfaches HTTP und CONNECT. Mehrere Header können dazu führen, dass Proxy-Richtlinie und nachgelagerter Parser unterschiedliche Host-Angaben auswählen. Die Änderung weist solche Anfragen zurück, bevor sie weitergeleitet oder über einen Unix-Socket geroutet werden. Die beschriebenen Tests umfassen gleiche und widersprüchliche Header in Origin-Form-, Absolute-Form- und CONNECT-Anfragen.
Der Alias-Schutz greift bei der beschriebenen Kombination aus ausgewählten, vermittelten Zugangsdaten und einem Zielhost mit Inspektions-Hook. Der Pull-Request prüft dazu unter anderem konfigurierte URL-Präfixe, sichere Pfade und die Auswahl zusammengeführter Basic-Auth-Felder. Die Tests decken außerdem Anbieter-Aliase und IPv6-Ziele ab.
