OpenAI Codex release notes: 0.142.1 löser Windows-proxy vid inloggning

OpenAI Codex fick en liten release som är lätt att missa om man inte sitter bakom en företagsproxy. Men för Windows-team som har PAC, WPAD eller statiska proxyregler kan den vara skillnaden mellan "Codex går inte att logga in i" och "Codex följer samma väg som resten av arbetsdatorn".

Codex CLI är OpenAI Codex som lokal terminalagent: den kan läsa, ändra och köra kod i den katalog där du startar den. En systemproxy är den nätverksväg operativsystemet använder för trafik ut från datorn. PAC är en proxyfil med regler, och WPAD är automatisk upptäckt av sådana regler i Windows-nätverk.

OpenAI Codex release notes: vad 0.142.1 ändrar

OpenAI publicerade Codex CLI 0.142.1 den 25 juni 2026. Release notes säger att versionen lägger till opt-in-stöd för Windows systemproxy vid autentisering, inklusive PAC, WPAD, statiska proxyinställningar och bypass-regler.

Källa: OpenAI Codex 0.142.1 release notes

Den underliggande pull requesten är tydligare än release-raden. Funktionen är avstängd som standard, så befintligt beteende ändras inte. När respect_system_proxy aktiveras kan Codex-ägda autentiseringsklienter på Windows använda den rutt Windows väljer för varje auth-URL. Om systemupplösningen inte går att använda faller den tillbaka till explicita proxyvariabler i miljön och sedan direkt anslutning. Anpassad CA-hantering ligger separat från proxyvalet.

Källa: PR #26708: PAC 3 - Add Windows system proxy resolver

Varför Windows-proxy i OpenAI Codex spelar roll

Det här är inte en ny agentförmåga. Det är rörmokararbete, vilket ofta är precis det som avgör om AI-verktyg går att använda i en riktig organisation.

Om en skola, byrå eller industrimiljö kör Windows med centrala proxyregler kan webbläsaren fungera medan en terminalapp fastnar vid inloggning. Codex 0.142.1 gör det möjligt att testa autentiseringen mot samma PAC-, WPAD-, proxy- och bypass-logik som Windows redan använder, men bara när funktionen uttryckligen slås på.

För Hammer-läsare är den praktiska poängen enkel: innan ni kopplar Codex till fler interna repo, MCP-servrar eller byggmiljöer, kontrollera först att inloggning, proxyväg, miljövariabler och granskningslogg är begripliga. Det är Tool Forge-arbete i liten skala: inte mer policytext, utan en körbar kontrollpunkt.

Kort exempel: använd nyheten i Codex

Mänskligt steg: uppdatera en Windows-miljö till Codex CLI 0.142.1 och slå bara på funktionen om er IT- eller plattformsägare vill att Codex-autentisering ska följa Windows systemproxy. PR:n visar funktionsnamnet som respect_system_proxy under [features].

[features]
respect_system_proxy = true

Källa: PR #26708: end-user behavior for respect_system_proxy

Kopiera sedan den här prompten till Codex efter att miljön redan är uppdaterad och konfigurerad:

Granska det här projektets Codex-inloggningsflöde för en Windows-miljö bakom företagsproxy. Utgå från att respect_system_proxy redan är aktiverat. Skriv en kort testplan: hur vi bekräftar inloggning, vilka PAC/WPAD/statiska proxy- och bypass-fall som ska noteras, vilka proxyrelaterade miljövariabler som kan påverka resultatet, och var en människa ska godkänna nästa steg innan Codex får ändra repo eller köra kommandon.

Bra svar bör innehålla:

• versions- och konfigurationsantagandet, så testet inte blandas ihop med äldre Codex-beteende
• en konkret kontroll för PAC, WPAD, statisk proxy, bypass och miljöproxyvariabler
• en tydlig gräns mellan autentiseringstest och verkliga kodändringar
• en kort loggrad eller körkvitto som en människa kan spara

Vad du bör bevaka härnäst

0.142.1 är en smal stabil release. Samtidigt finns alpha 0.143.0-spåret i npm-registret, men de senaste alpha-releasebodyna jag kontrollerade var bara generiska "Release 0.143.0-alpha"-poster utan egen användartext. Därför är dagens publicerbara OpenAI Codex changelog-signal Windows-proxy vid autentisering, inte ett bredare råd att hoppa på alpha.

Källa: npm-registret för @openai/codex