OpenAI Codex release notes: 0.142.2 gör MCP-verktyg lättare att hitta

OpenAI Codex fick en liten men praktisk Codex changelog-signal efter förra posten: 0.142.2 ändrar hur Codex hittar MCP-verktyg, hur macOS-klienter kan följa systemproxy och hur plugins visas i mörkt läge. 0.142.4 är nu senaste stabila npm-versionen, men GitHub-release notes säger att 0.142.3 och 0.142.4 inte har några identifierade användarnära ändringar. Därför är den viktiga nyheten fortfarande 0.142.2.

Codex CLI är OpenAI Codex som lokal kodagent i terminalen: den kan läsa, ändra och köra kod i den arbetsyta du ger den. MCP, Model Context Protocol, är ett sätt att koppla en AI-agent till externa verktyg och datakällor med tydligare gränser. En approval gate är en punkt där en människa eller policy måste godkänna en riskfylld åtgärd innan agenten fortsätter.

Källa: OpenAI Codex GitHub release 0.142.2 och npm-registret för @openai/codex.

OpenAI Codex release notes: vad ändrades i 0.142.2?

Den mest användbara ändringen för praktiska team är att MCP-verktyg nu använder tool search som standard när det stöds. Det låter torrt. I vardagen betyder det att Codex kan upptäcka rätt verktyg i en MCP-koppling bättre, samtidigt som releasen uttryckligen behåller kompatibilitet med äldre modeller och leverantörer.

Release notes innehåller också flera mindre, men viktiga, driftpunkter:

• macOS-autentisering kan följa systemproxy, PAC och WPAD när respect_system_proxy är aktiverat.
• Plugins kan ha egna mörka logotyper via lokala manifest och fjärrkataloger.
• Appar kan visa rikare säkerhetsbuffring med serverstyrd synlighet och metadata för snabbare modeller.
• Remote stdio-MCP-servrar accepterar nu absoluta arbetskataloger skrivna i fjärrplattformens sökvägsformat.
• PowerShell-kommandon med AST-regioner som säkerhetsklassaren inte kan inspektera kräver nu godkännande.

Källa: OpenAI Codex GitHub release 0.142.2.

Varför MCP-tool search spelar roll för svenska team

Många Codex-piloter börjar som terminalhjälp i ett repo. Nästa steg blir ofta integration: GitHub, ärendehantering, interna dokument, byggloggar eller egna API:er. Då räcker det inte att agenten är smart. Den måste hitta rätt verktyg, förstå var gränserna går och lämna ett spår som går att granska.

Tool search i MCP är en sådan liten infrastrukturändring som gör större arbetsflöden mindre sköra. För Hammer-läsare är det särskilt relevant om ni redan testar Codex med egna MCP-servrar, fjärrmiljöer eller plugin-kataloger. Lägg energin på en enkel körjournal: vilka verktyg hittades, vilka åtgärder krävde godkännande, vilka nycklar eller miljövariabler behövdes, och vad ska redigeras bort ur loggar innan de delas.

Kort exempel: använd nyheten i Codex

Mänskligt steg: öppna den arbetsyta där ni redan kör Codex och säkerställ med er vanliga paket- eller klienthantering att ni använder en build som innehåller 0.142.2-ändringarna. npm-registret visar 0.142.4 som senaste stabila version, medan GitHub-release notes säger att de senare 0.142.3 och 0.142.4 bara är underhåll utan användarnära ändringar.

Källa: npm-registret för @openai/codex, release 0.142.3 och release 0.142.4.

Kopiera sedan in en kort agentinstruktion:

Inspect this Codex workspace for MCP and plugin readiness. List which MCP tools are discoverable, which actions would need approval before execution, and whether proxy or credential notes are documented for macOS or Windows users. Do not edit files. Return a short run receipt with risks, missing docs, and one safe next test.

Bra svar bör visa:

• vilka MCP-verktyg Codex faktiskt kan se, inte bara vilka som nämns i dokumentationen
• vilka åtgärder som borde gå genom en approval gate innan de körs
• om proxy, API-nycklar, miljövariabler och redigering av loggar är tillräckligt dokumenterade
• ett nästa test som är litet nog att granskas av en människa

Vad du bör testa nu

Om ni använder Codex utan MCP räcker det att notera versionen och gå vidare. Om ni däremot kopplar Codex till interna verktyg är 0.142.2 en bra ursäkt att göra en snabb kontrollrunda: kör en läsande uppgift, be Codex beskriva vilka verktyg den ser, och kräv mänskligt godkännande innan den ändrar filer, kör PowerShell eller använder känsliga anslutningar.

Hammer Automation skulle placera det här i Tool Forge/Verktygssmide: inte som ett stort plattformsprojekt, utan som ett sätt att göra en fungerande Codex-pilot mer driftbar. Börja med tool discovery, scoped permissions, hemligheter via miljövariabler eller secret manager, redaktion av loggar och en enkel granskningslogg över varje körning.