OpenAI shipped a new stable Codex CLI on June 18, then pushed seven alpha builds of the next version in roughly two days. If you are deciding what to install, that churn is the signal — and it points back to the stable tag, not away from it.
What v0.141.0 Delivers — and Why Seven Alphas Don't Replace It
For broad 2026 use, install rust-v0.141.0 — it is the build GitHub marks as 'Latest' and OpenAI documents in its changelog. Codex CLI is the open-source, Rust-built terminal coding agent in the openai/codex repository (not the older Codex language model). Version 0.141.0 was published 2026-06-18 (04:43 UTC, tag commit 3fb8166, 151 assets), and OpenAI's changelog ships an exact install command :
npm install -g @openai/codex@0.141.0The reason to skip the newer numbers is release-channel status, not feature scarcity. Every v0.142.0 build is still a pre-release. GitHub lists seven alpha tags, v0.142.0-alpha.1 (Jun 18) through alpha.7 (Jun 20, 00:40 UTC, tag commit b34b303), each explicitly labeled 'Pre-release'. Seven alphas in roughly 48 hours signals active churn, not a stabilizing branch — and none of the alpha tags carries a consolidated changelog distinguishing it from v0.141.0.
| Signal | rust-v0.141.0 | v0.142.0-alpha.7 |
|---|---|---|
| GitHub label | Latest (stable) | Pre-release |
| Published | 2026-06-18 | 2026-06-20 |
| Documented install | Yes (changelog) | No production dist-tag |
| Consolidated changelog | Yes | None |
The scope of the in-progress work underlines the point. The full compare from rust-v0.141.0 to alpha.7 spans 135 commits, 757 files changed, and 42 contributors — large enough that GitHub's browser comparison page could not render it fully. Meanwhile, the alpha.7 release page notes only '2 commits to main since this release', confirming these are fast intermediate builds rather than a release candidate. For most developers, 0.141.0 is the build to run today.
Noise Relay: Authenticated, Encrypted Executor Channels in 0.141.0
The headline addition in rust-v0.141.0 is a Noise relay: an authenticated, end-to-end encrypted transport for remote executors that establishes trust at the channel layer before any code runs . In practice, two machines negotiate a verified, encrypted session first, and only then does Codex dispatch work across it — execution never precedes the handshake. The release, published 2026-06-18, ships this as net-new infrastructure rather than a patch to existing local channels .
Two properties matter for anyone running Codex across more than one host. First, the transport is built on the Noise protocol framework, so the channel itself carries authentication and confidentiality — there is no plaintext inter-executor messaging to intercept or spoof on the wire . Second, cross-platform remote execution now preserves each executor's native working directory, shell, and filesystem permission paths instead of flattening them to a host-side default . A Windows executor keeps its PowerShell context and permission model; a Linux executor keeps its shell and path semantics. The relay coordinates them without erasing their environment-specific behavior.
"Authenticated, end-to-end encrypted Noise relay channels for remote executors, with cross-platform remote execution that preserves executor-native working directories, shells, and filesystem permission paths." — rust-v0.141.0 release notes (source: openai/codex)
What this enables is a multi-machine Codex deployment with a defined trust boundary. Before, you either ran a single local agent or stitched together your own transport; now the relay is a first-party channel where identity is verified up front and traffic between executors is encrypted by default. For teams distributing builds, tests, or sandboxed tasks across a fleet, that removes a class of "did this message really come from my executor?" questions from the threat model.
The contrast with the prior stable build sharpens the point. Version 0.140.0, released 2026-06-15, shipped workflow features such as /usage views and codex delete, but had no relay capability — executor channels were local-only . Moving 0.140.0 → 0.141.0 is therefore not a cosmetic bump: it is the arrival of inter-executor transport that did not exist three days earlier. For more on the broader release, OpenAI documents the full 0.141.0 notes and its place in the release timeline.
Executor Extensions: Per-Thread Activation and Deduplication in 0.141.0
Executor plugins in rust-v0.141.0 activate stdio MCP servers per thread rather than once globally, and the extension catalog is now auth-aware — it reflects the authenticated user's identity instead of exposing a flat list to every thread . For anyone running multi-threaded Codex sessions, that is the practical headline: the place where MCP servers and capabilities get wired in moved from a shared process-wide registry to a per-thread one.
The per-thread activation change matters because a globally activated stdio server shares state across every concurrent thread. When two threads talk to the same long-lived MCP process, one thread's open handles, cached context, or in-flight requests can leak into another. Scoping activation to the thread that requested it removes that cross-thread bleed — each thread gets its own server lifecycle, so a busy agent loop and an interactive session no longer step on each other through a shared plugin process .
Auth-aware discovery extends the same principle to what each thread can even see. Rather than presenting a single global plugin list, discovery now routes capabilities and surfaces marketplaces according to the authenticated identity, with "created-by-me" filtering so only extensions owned by the authenticated user appear in the catalog by default . The default view is your own extensions, not everything installed on the host.
The fourth piece is deduplication. When multiple extensions each declare the same App or MCP surface, 0.141.0 collapses the conflicting declarations instead of registering the capability twice. That prevents duplicate capability registrations — two extensions both claiming, say, the same tool name no longer produce two competing entries that the router has to disambiguate at call time .
Taken together, these are governance-and-isolation changes more than new features: capability routing, deduplication, and auth-scoped discovery make the plugin layer predictable under concurrency. Like the rest of the release, the notes document no breaking changes, so teams adopting per-thread extensions inherit the tighter isolation without reworking existing plugin configs .
The SQLite WAL Pin and Windows Hardening
The most consequential reliability fix in v0.141.0 is data-integrity work: the bundled SQLite is now pinned to a version that includes the WAL-reset patch, closing a path to journal-mode data loss during long-running Codex sessions . Codex keeps thread and session state in SQLite under write-ahead logging (WAL), where a faulty WAL reset can corrupt or drop committed records. Pinning the dependency means a session that stays open for hours no longer risks silently losing history to that bug — a quiet but operationally significant change for anyone running extended agent sessions.
Windows users get two targeted hardening fixes in the same release. The execution environment now performs automatic stale-credential repair, so a session no longer wedges when cached credentials go bad mid-run, and the PowerShell foreground timeout is longer before Codex backgrounds the process — fewer commands get prematurely pushed into the background while still doing real work . Both address failure modes that disproportionately hit Windows sandboxing, where credential and process-lifetime handling differ from POSIX shells.
Two correctness fixes round out the set. Hook trust bypass now persists correctly across codex exec thread start and resume; in prior builds that trust state was silently dropped, meaning a hook you had already approved could be re-evaluated or blocked on resume . And TLS P-521 certificate signature support was added, so enterprise proxies using P-521 elliptic curves — which previously caused connection rejection at the handshake — now negotiate cleanly . For teams behind corporate proxies, that is the difference between Codex connecting and failing before a single request goes out.
| Fix | Problem it solves | Who it affects |
|---|---|---|
| SQLite pinned to WAL-reset patch | Journal-mode data loss in long sessions | All users running extended sessions |
| Stale-credential auto-repair | Sessions wedging on bad cached credentials | Windows sandbox users |
| Longer PowerShell foreground timeout | Commands backgrounded prematurely | Windows sandbox users |
| Hook trust persists across exec resume | Approved hook trust silently dropped on resume | Teams using codex exec hooks |
| TLS P-521 signature support | Handshake rejection on P-521 proxy certs | Enterprise proxy deployments |
None of these introduces a configuration change or breaking behavior — the v0.141.0 notes document no breaking changes — so the practical takeaway is that the upgrade removes failure modes rather than adding surface to manage .
0.141.0 Caching: Faster Repeated Lookups and a 64 MiB Hard Cap
The 0.141.0 performance work targets a specific failure mode: long, tool-heavy sessions that slowly accumulate latency and memory. Tool search results are now cached per session, so repeated lookups no longer re-run the full search on every invocation — the cost is paid once and amortized across the rest of the conversation . The release shipped as the current stable build on 2026-06-18 and documents no breaking changes, so these gains arrive without a configuration step .
The companion change eliminates repeated request and history copies that previously piled up in large tool-call sessions. The effect is cumulative rather than constant: at low call counts the difference is negligible, but at high call counts the avoided copying becomes a measurable latency reduction . If your agent loops involve hundreds of tool invocations per thread — code search, file reads, MCP calls — this is the line item that compounds in your favor.
Memory gets a hard ceiling. Prompt-image caching is now bounded to 64 MiB, which prevents unbounded heap growth on workflows that attach many images across a long conversation . Rather than letting attached images accumulate until the process bloats, the cache evicts within that budget — a predictable cap matters more for stability than a larger one.
Two smaller adjustments round out the section:
- Feedback uploads capped at eight related threads — feedback submissions now bundle at most eight associated threads, bounding upload size instead of sweeping in an open-ended set .
- Terminal resize reflow is always enabled — previously opt-in behind a manual flag, reflow on resize is now on by default, so panes re-wrap correctly without configuration .
Taken together, these are reliability-by-default changes: less re-computation, a bounded image cache, smaller feedback payloads, and reflow that no longer needs a flag. None of them alters your workflow surface — they reduce the ways a long session degrades.
What the 0.142 Alpha Branch Contains — and What's Temporarily Unguarded
The v0.142 alpha branch is where Codex CLI's platform and enterprise governance work is landing, and it is also where the sharpest caveats live — including one component that ships intentionally without a process sandbox. The narrower alpha.4→alpha.7 compare shows late changes that touch usage accounting, network egress, remote execution, web search, and the model-visible context surface . None of this is in the documented stable release; the only published install command remains npm install -g @openai/codex@0.141.0 , so treat everything below as evaluation-grade.
Four changes matter most for integrators:
- Rollout-budget exhaustion aborts turns at usage-accounting boundaries. When a shared budget is consumed, the turn is cut at the accounting boundary rather than running past quota — a new governance layer for teams sharing rollout budgets across agents .
- Network approvals are scoped per execution environment. Each environment gets its own HTTP/SOCKS proxy listeners, and the behavior is fail-closed: no approval means no egress. This replaces a single global approval surface with environment-level isolation .
- Indexed web search adds a third state. The earlier two-mode setup gains an indexed mode alongside cached and live, while the disabled state remains — giving operators a middle ground between stale results and full live access .
- Terminology and context limits tightened. The offline/online naming is replaced by cached/live, but the wire values stay backward-compatible, so existing configs keep parsing. Separately, skill descriptions are preserved at full fidelity but capped to 1024 Unicode characters when rendered into model-visible catalogs or
skills.list.
The change that needs a flag in your rollout notes is remote unified-exec. The alpha now sends the original argv to the exec-server — useful, because the executor sees the command exactly as issued — but the PR text is explicit that the sandbox is not yet wired up:
"Remote unified-exec commands are temporarily sent without a process sandbox until follow-ups land." — OpenAI Codex pull request notes (source: releasebot.io)
This is documented churn, not an oversight: the maintainers flagged the gap and pointed at follow-up PRs. But combined with the new per-environment network approvals, it means an alpha.7 remote executor can run commands outside the process sandbox while you are still validating egress controls — a combination worth isolating in a canary, not pushing to a shared fleet. The branch also advanced tokio-tungstenite for Happy-Eyeballs-style websocket recovery, so connectivity behavior changed underneath these features too .
There is still no consolidated stable v0.142.0 changelog: no disclosed model bump, no GA date, and the best record of these changes is the compare view and individual PR summaries rather than release notes . If your decision hinges on environment-scoped network approvals or the new web-search modes, validate them against the full alpha compare and wait for the promoted stable tag before broad rollout.
Which Build to Install Right Now
Install the stable release: npm install -g @openai/codex@0.141.0. rust-v0.141.0 is the build GitHub marks as 'Latest' (published 2026-06-18) and the only version with a complete OpenAI changelog entry and the exact install command above . Its notes document no breaking changes and no stability caveats, which makes it the correct default for any production or shared environment .
Opting into the alpha line is deliberate work. No npm production dist-tag exists for any v0.142 alpha — a standard npm install and Homebrew both resolve to 'Latest' (v0.141.0), so you must request an explicit pre-release tag to get alpha.7 .
The only reasons to track the alpha branch are its meaningful 0.142-exclusive additions: environment-scoped network approvals with per-environment proxy listeners, the indexed web-search mode, rollout-budget enforcement at usage-accounting boundaries, and orchestrator skill governance . If none of those is on your critical path, wait for the promoted stable 0.142.0 tag and its release notes rather than running churn — seven alphas landed in roughly 48 hours, with no consolidated changelog yet .
If you do pilot an alpha, validate these four areas before trusting it anywhere shared:
- Exec sandbox behavior — remote unified-exec commands are temporarily sent without a process sandbox until follow-ups land .
- Per-environment proxy listeners — confirm HTTP/SOCKS scoping and fail-closed behavior match your network policy.
- Websocket recovery — exercise reconnection under the Happy-Eyeballs-style path after the tokio-tungstenite advance.
- Skills rendering — check descriptions in the model-visible catalog, now capped to 1024 Unicode characters .
The takeaway is simple: ship rust-v0.141.0 today, keep v0.142.0-alpha.7 on an explicit opt-in channel with rollback, and let a specific 0.142 feature — not the version number — decide when you move.
Frequently asked questions
What is the Noise relay in Codex CLI v0.141.0?
The Noise relay is an authenticated, end-to-end encrypted transport layer for executor communication, built on the Noise protocol and shipped in rust-v0.141.0 . It lets you run Codex across multiple machines without exposing plaintext RPC between the agent and its remote executors. Crucially, the channel preserves each executor's native working directory, shell, and filesystem permission paths, so a remote executor behaves like a local one rather than a stripped-down proxy .
Should I install v0.142.0-alpha or stick with v0.141.0?
Stick with v0.141.0 unless you need a specific alpha-only feature. The v0.142 line produced seven alpha builds in roughly 48 hours — alpha.1 on 2026-06-18 through alpha.7 on 2026-06-20 — which signals active churn, not a stabilizing branch . One alpha explicitly ships remote unified-exec without a process sandbox until follow-up PRs land . By contrast, v0.141.0 documents no breaking changes, has a full OpenAI changelog entry, and is the only build with a documented install command, npm install -g @openai/codex@0.141.0 .
What does the SQLite WAL pin prevent in Codex CLI?
It prevents a class of journal-state corruption that could cause data loss on long-running sessions. Codex bundles its own SQLite rather than relying on the system copy, and a known WAL-mode reset bug in older SQLite versions could corrupt journal state during extended use. In v0.141.0, the bundled SQLite is pinned to a build where that fix is applied, eliminating the data-loss risk without asking users to manage a system SQLite install themselves .
How many commits separate v0.141.0 from v0.142.0-alpha.7?
135 commits, spanning 757 files changed across 42 contributors — large enough that GitHub reported the browser comparison was too large to render fully . That is not a patch-level gap; it is a substantial branch divergence touching security, sandboxing, networking, and configuration surface. Treat any 0.142 alpha as something to validate in a canary channel before production rollout, not as a drop-in successor to v0.141.0 .
Does the 0.142 alpha change what the model sees in skills catalogs?
Yes. Skill descriptions are preserved at full fidelity in storage but capped to 1024 Unicode characters when rendered into model-visible catalogs — the skills.list surface . Both orchestrator-provided skills and Codex Apps entries are affected. Separately, the alpha line renames the offline/online states to cached/live while keeping the underlying wire values backward-compatible, so existing offline/online consumers continue to work without changes .
