OpenAI's Codex CLI just did something its changelog never mentioned: in roughly a day, its continuous-delivery pipeline cut ten sequential alpha builds on the 0.143.0 track — and not one of them shipped human-readable release notes.
What the CD pipeline just emitted: ten Codex alphas in sequence
Between June 23 and June 24, 2026, the open-source Codex CLI repository published ten sequential pre-release tags — rust-v0.143.0-alpha.4 through alpha.13 — in a single rolling 24-hour window. The first, alpha.4, landed June 23 at 04:03 UTC (commit c24447e, 151 assets) ; the tenth, alpha.13, landed June 24 at 03:24 UTC (commit a67f3ac, 151 assets) — an elapsed span of 23 hours 21 minutes.
Quick Answer: Codex CLI published ten sequential 0.143.0 alpha builds (alpha.4 through alpha.13) in a 23-hour-21-minute window across June 23–24, 2026 — automated pre-releases from its CD pipeline, each full build carrying 151 cross-platform assets, with no curated "What's Changed" notes on any of them.
The intermediate tags filled the window at a steady cadence rather than in a single burst. On June 23 (UTC): alpha.5 at 08:23, alpha.6 at 13:06, alpha.7 at 16:34, and alpha.9 at 18:56. On June 24: alpha.11 at 01:17 and alpha.12 at 02:23 . Because the sequence crosses two UTC calendar dates, "ten in a day" is accurate only as a rolling 24-hour description, not a single UTC date.
Each full-asset entry carries 151 cross-platform binaries — macOS, Linux, and Windows on x86_64 and aarch64, plus checksums and signatures — emitted by the repository's automated release workflow rather than a human committer . That asset count is the tell: this is a packaging pipeline cutting tags on demand, not a series of hand-curated milestones.
The track did not stop at alpha.13. The same 0.143.0 series continued through alpha.14, .15, .16, .21, .22, and .25 across June 24–25, while earlier alpha.1–alpha.5 builds appeared June 22–23 — putting the full alpha track past 20 published tags in under four days .
Why alpha.8 and alpha.10 carry 2 assets, not 151
Two entries break the pattern. Every full alpha page in the series carries 151 cross-platform assets, but alpha.8 (commit f2a0f9d, tagged 2026-06-23 17:17 UTC) and alpha.10 (commit 1ec3def, tagged 2026-06-23 23:51 UTC) carry only 2 assets each .
The origin differs too. Both were tagged by the user account rka-oai rather than by the repository's automated release workflow that produced every other entry in the track . With no binaries, no checksums, and no signatures attached, neither tag is install-ready — functionally unusable as an end-user build.
| Tag | Commit | Tagged (UTC) | Assets | Origin |
|---|---|---|---|---|
| alpha.8 | f2a0f9d | 2026-06-23 17:17 | 2 | rka-oai |
| alpha.10 | 1ec3def | 2026-06-23 23:51 | 2 | rka-oai |
| Other alphas | varies | — | 151 | release workflow |
Three readings fit the evidence equally well:
- Intentional lightweight markers — minimal internal tags cut by hand to bookmark a commit, never meant to ship binaries.
- Partial or failed CI runs — release jobs that only partially executed, leaving the tag without its packaging step.
- Staging artifacts — internal scaffolding that became publicly visible without being intended for distribution.
The public record does not resolve which. Both tag pages exist and are indexable, but neither carries a "What's Changed" body or any attached rationale . For anyone scanning the release list, the practical signal is simpler: an asset count of 2 marks a tag you cannot install, whatever its intent.
What the engineering spread covered in 65 revisions
The clearest "what changed" signal is GitHub's own compare between the two full-asset endpoints. With base c24447e (alpha.4) and head a67f3ac (alpha.13), the refs are reported as diverged: alpha.13 is 65 commits ahead and 1 behind . That shape — broad and multi-subsystem rather than a single hotfix — is the substance here.
The file-level diff lands across five areas at once: the Codex App Server protocol, MCP and plugins, the Windows filesystem sandbox, remote execution and trust, and Code Mode host scaffolding . The schema-level moves matter most to anyone consuming the server API — a new ThreadExtra type in the TypeScript outputs, changed thread processors, and newly added code-mode host protocol files can ripple into clients without a feature flag to warn them.
| Subsystem | Representative change in the range |
|---|---|
| App Server protocol | New ThreadExtra TypeScript type; changed thread processors; added code-mode host protocol files |
| MCP & plugins | Tool-call error metrics added; install/uninstall analytics split into local vs remote plugin IDs; manifest path resolution decoupled from install location |
| Windows sandbox | Proxy state preserved across sandbox helper invocations; PAC/WPAD/static proxy support; PowerShell commands needing safety approval handled more robustly |
| Remote execution & trust | view_image paths resolved in the selected environment; connected-account email injected into app-review metadata for trusted Codex Apps; exec-server reports its working directory |
Read together, the commit messages name an integration and stabilization train, not a headline feature: preserve proxy state for Windows sandbox helpers, allow image generation with provider auth, use current step environments for tools, add MCP tool-call error metrics, separate local and remote plugin analytics IDs, and fix stale approval-policy test references . Many added or updated tests travel alongside the code, which is consistent with hardening rather than shipping.
"Sixty-five commits spread this evenly across protocol, sandbox, and telemetry read like a CD train merging stabilization work, not a curated milestone — the test churn is the tell," — editorial assessment based on the public compare log (source: GitHub compare, alpha.4…alpha.13).
For integrators, the practical takeaway is which surfaces to retest: the App Server schema for client compatibility, MCP error-metric paths for telemetry parsing, and Windows proxy and PowerShell approval flows for sandboxed execution. None of this is announced as user-facing, but the schema and trust-metadata changes are the kind that quietly break downstream consumers if a pin moves.
No curated notes on any alpha — what that means for practitioners
None of the alpha.4 through alpha.13 pages carry a populated "What's Changed" section . That is the practical difference from the stable line: the 0.142.0 and 0.142.2 entries ship categorized, human-written notes broken out per subsystem — /usage credits, plugin reorg, MCP fixes — while the alphas leave the changelog field empty or sparse .
So the only reconstruction path is the one used in the previous section: the raw GitHub compare between two tag commits. No diff is pre-digested. To learn what moved between alpha.4 and alpha.13 — 65 commits ahead, 1 behind — you read the commit log yourself . There is no per-build summary to skim.
For CI that auto-updates to the latest alpha, that matters concretely:
- Behavior can shift between runs with no audit trail beyond the commit history.
- A pin to
0.143.0-alpha.Nmay be superseded within hours, since the track pushed past 20 builds in under four days . - Teams that do not pin explicitly inherit schema and trust-metadata changes silently.
Read charitably, this is intentional. Alpha tags from an automated pre-release pipeline are snapshot references for internal QA validation, not communication artifacts for downstream consumers. OpenAI's own install documentation steers most users to the stable channel rather than the alpha track . The unwritten contract: if you opt into an unannounced build, you accept the commit log as your only changelog.
Who benefits from the alpha series — and who can ignore it
Most teams should treat the 0.143.0 alpha track as noise. The series matters only to a narrow set of practitioners who are deliberately probing pre-release behavior; everyone running Codex through a default install channel will neither see nor need these builds.
Track the alpha series if you fall into one of these cases:
- Validating a specific fix on the pre-release channel — for example, confirming the Windows filesystem-sandbox proxy-state preservation or the
view_imagepath resolution landed in the alpha.4-to-alpha.13 range . - Integrating plugins or MCP against the unreleased app-server schemas, including the new
ThreadExtratype and changed thread processors . - Enterprise-validating Windows sandbox proxy behavior before a fleet rollout, ahead of the curated system-proxy support shipped in stable 0.142.x .
Ignore it entirely if you install Codex via the npm package @openai/codex, the Homebrew cask codex, or the standard standalone installer. Those default to the stable channel and will not pick up a 0.143.0-alpha.N build automatically .
If you must pin, two rules apply. First, any 0.143.0-alpha.N may be superseded within hours, so a pin is a snapshot, not a stable floor. Second, anchor only to a full-asset tag carrying 151 cross-platform assets — never to a 2-asset lightweight tag like alpha.8 or alpha.10, which lack the packaged binaries you would actually deploy .
The concrete takeaway: for most teams the recommended target is stable 0.142.2, which ships complete curated notes covering Windows and macOS system-proxy support, several MCP fixes, and dark-mode plugin logos . Pin there, and revisit when 0.143.0 finalizes with its own changelog — not before.
Frequently asked questions
What is Codex 0.143.0-alpha and why are there so many builds so fast?
Codex 0.143.0-alpha is the pre-release development track of OpenAI's open-source, Rust-built terminal coding agent. The alpha tags are machine-generated snapshots, not hand-curated milestones: a continuous-delivery pipeline cuts a fresh pre-release tag on each qualifying merge to the 0.143.0 branch. That is why alpha.4 through alpha.13 — ten sequential version numbers — landed across roughly 23 hours and 21 minutes . The cadence reflects a high-velocity merge queue, not a special event.
Why do alpha.8 and alpha.10 only have 2 assets instead of 151?
The full alpha pages carry 151 cross-platform assets each (macOS/Linux/Windows binaries plus checksums and signatures), but alpha.8 and alpha.10 expose only 2 assets . Both were tagged by an individual account (rka-oai) rather than the automated release workflow, on 2026-06-23 at 17:17 and 23:51 UTC respectively . They are likely lightweight internal markers or partial CI job artifacts — the public record does not confirm which.
What actually changed between alpha.4 and alpha.13?
GitHub's official compare reports alpha.13 as 65 commits ahead of and 1 behind alpha.4 . The file-level spread is broad rather than a single hotfix: app-server protocol schemas (including a new ThreadExtra type), MCP tool-call error metrics, plugin install/analytics changes, Windows sandbox proxy state, remote-environment and view_image path handling, and trust metadata for Codex Apps, plus many added tests . It reads as an integration and stabilization train, not a headline feature.
Should I pin a Codex 0.143.0-alpha in production or CI?
For most teams, no. No curated release notes exist for any alpha in this series, builds can be superseded within hours, and any regressions arrive unannounced . As of the research date the developer changelog still topped out at 0.142.2 with no finalized 0.143.0 entry . Stable 0.142.2 — which ships complete notes covering Windows/macOS system-proxy support and several MCP fixes — is the correct target until 0.143.0 finalizes.
How do I read what changed in a specific alpha when there are no release notes?
Use the GitHub compare URL between the two tag commits you care about; the Files Changed view and the commit list are the only changelog available. For this burst, comparing alpha.4 (base c24447e) against alpha.13 (head a67f3ac) surfaces the full 65-commit diff and its merge base 27f22b5 . No human-readable summary is provided for any alpha in the series, so the commit messages themselves are the signal .
