OpenAI Codex release notes: 0.143.0-alpha.36 gör installation och pluginversioner tydligare

Den här OpenAI Codexuppdateringen är inte en ny stor knapp. Den är mer jordnära, och därför rätt användbar: 0.143.0-alpha.36 gör installationsflödet mindre skört och gör versionsdata från fjärrplugin synligare. För team som testar Codex CLI i riktiga kodbaser är det exakt sådant som avgör om en uppdatering känns hanterbar eller bara "något gick fel".

Codex CLI är OpenAI:s lokala kodagent i terminalen. En kodagent kan läsa kod, föreslå ändringar och köra kommandon i den katalog där du startar den. I den här releasen är 0.143.0-alpha.36 fortfarande alpha, medan npm-registrets latest låg kvar på 0.142.5 när kontrollen gjordes.

Källor: GitHub release 0.143.0-alpha.36, npm-registret för @openai/codex

OpenAI Codex release notes: vad ändrades i 0.143.0-alpha.36

Två ändringar är mest värda att notera.

Först: det fristående installationsprogrammet återanvänder nu GitHub release-metadata i stället för att göra flera separata, oautentiserade GitHub API-anrop när det hittar version, paket, checksumma och asset-digests. Enligt PR:en kunde ett enda installationsförsök tidigare göra upp till fyra metadataanrop. När GitHubs delade gräns för oautentiserade anrop tog slut kunde en giltig release misslyckas, och ett 403 kunde beskrivas som om releasefilerna saknades. Nu ska installationsprogrammet återanvända ett metadataresultat och rapportera metadatafel som möjlig GitHub-tillgänglighet eller gräns för anrop, inte som saknade releasefiler.

Källa: openai/codex PR #31056, fix(install): reuse GitHub release metadata

Andra ändringen: Codex exponerar versioner från fjärrplugin. Ett plugin är ett tilläggspaket som kan ge Codex extra funktioner eller kopplingar. PR:en lägger till PluginSummary.version för versioner som annonseras av fjärrpluginmarknadsplatser, bevarar backendens releaseversion i plugin/installed, och behåller localVersion som versionen av det lokalt materialiserade paketet. Det låter tråkigt. Det är det inte om du försöker förstå varför två utvecklare ser olika pluginbeteende.

Källa: openai/codex PR #30981, expose remote plugin versions

Det finns också två mindre driftssignaler i samma alpha: feedbackbilagor med gzip får rätt MIME-typ i stället för att behandlas som text, och buffergränssnittet kan läsa metadata från response events. Jag skulle inte bygga en hel uppgraderingsplan på de två, men de säger något om riktningen: Codex blir mer beroende av tydliga kvitton, inte bara smarta svar.

Källor: PR #30796, MIME types for path-backed feedback attachments, PR #31064, buffering metadata from response events

Mänskligt steg innan du testar alpha-spåret

OpenAI:s CLI-dokumentation säger att den fristående macOS/Linux-installationen görs med curl -fsSL https://chatgpt.com/codex/install.sh | sh, och att en fristående installation uppgraderas genom att köra installern igen. Det är ett mänskligt steg, inte något du ska stoppa in i en agentprompt.

Eftersom 0.143.0-alpha.36 ligger på alpha-spåret bör svenska team behandla den som ett test i en avgränsad arbetsyta. Behåll stabil version för produktion tills ni faktiskt vill verifiera installern, pluginversioner och loggkvitton. Om pluginen har åtkomst till repo, ärendehantering eller kundsystem: använd env vars eller secret manager, scoped tokens, godkännandesteg och en kort körlogg. Det räcker långt utan att göra testet defensivt.

Källa: OpenAI Codex CLI-dokumentation

Kort exempel: använd nyheten i Codex

Mänskligt steg först: öppna en testarbetsyta där Codex redan är installerat på den kanal du vill kontrollera. Kör inte uppdateringar från agentprompten.

Kopiera sedan in detta i Codex:

Inspect this Codex workspace for alpha 0.143.0-alpha.36 readiness. Do not edit files and do not run installs. Return one short receipt with: current Codex channel or version if visible, install path or runbook notes, whether installer failures would be logged as GitHub availability or rate-limit issues rather than missing assets, any remote plugins with explicit version information, and one human review step before a wider rollout.

Bra output bör:

• skilja stabil 0.142.5 från alpha 0.143.0-alpha.36
• visa om teamet använder fristående installer, npm eller annan paketering
• nämna pluginversioner utan att anta att alla plugin är godkända
• avsluta med ett tydligt mänskligt beslut före bredare utrullning

Vad Hammer skulle testa i ett verkligt automationsflöde

För ett nordiskt team är den praktiska frågan enkel: kan vi uppdatera Codex och förstå vad som hände om något går fel? Den här alpha-releasen pekar på bättre installationsdiagnostik och bättre plugininventering. I ett Tool Forge/Verktygssmide-upplägg skulle jag börja med en uppdateringskörning i ett repo, samla versionskvitto, pluginlista, eventuella installerfel och mänskligt godkännande i samma anteckning. Sedan kan teamet avgöra om Codex ska få fler arbetsflöden, inte bara fler prompts.