OpenAI's Codex coding agent shipped six tagged pre-releases of version 0.142.0 in under 36 hours, but the release notes never showed up. Here is what actually landed, and who needs to care.
The rapid 0.142 build sequence: what happened and who it affects
Codex (the Rust-built, open-source terminal coding agent in the openai/codex repo) cut six rust-v0.142.0 alpha builds in roughly two days, from alpha.1 on June 18 at 05:51 (commit d3b5279) to alpha.6 on June 19 at 20:29 (commit fc02182) . Each alpha is marked Pre-release and ships 151 cross-platform binary assets .
| Tag | Timestamp (UTC) | Commit |
|---|---|---|
| 0.142.0-alpha.1 | Jun 18, 05:51 | d3b5279 |
| 0.142.0-alpha.2 | Jun 18, 20:49 | 391b1b7 |
| 0.142.0-alpha.3 | Jun 19, 00:32 | cc0dfaa |
| 0.142.0-alpha.4 | Jun 19, 09:39 | a3ebfe4 |
| 0.142.0-alpha.5 | Jun 19, 19:40 | d76e3e1 |
| 0.142.0-alpha.6 | Jun 19, 20:29 | fc02182 |
These are iterative cuts of one upcoming minor version, not six independent feature drops. They sit on top of stable 0.141.0, published June 18 at 04:43, which GitHub still flags as Latest . OpenAI's developer changelog also tops out at 0.141.0 with no 0.142.0-alpha entry .
Who this touches:
- Stable-channel users stay on 0.141.0; nothing changes unless you opt in.
- Prerelease testers pull the alphas via
npm install -g @openai/codex@alphaor direct binary download from the tagged release.
Per-alpha attribution is unconfirmed. Because Codex alpha notes are cumulative, individual changes can't be pinned to a specific alpha number, and some of the six tags may be CI re-cuts rather than feature increments. The project knows this is a problem: issue #21682 explicitly asks for published changelogs, prerelease notes, docs sync, and migration examples . The build sequence moved fast; the documentation didn't follow.
Noise relay: how remote executors got authenticated encryption
The biggest change in the 0.142 window is how Codex talks to remote executors. A cluster of commits (connection-lifecycle work in #28674, #28683, and #29025) rewires the remote environment session so that traffic now runs over authenticated, end-to-end encrypted channels built on the Noise protocol framework, replacing the earlier unencrypted relay paths . For developers running agents against machines they don't physically control, that closes a real interception gap in the transport layer.
Encryption is only half of it. The same release line tightens environment fidelity, making a remote executor behave like itself rather than like the host that dispatched the job. "Keep remote exec commands native to the executor" (#29099) preserves the executor's working directory, shell choice, and filesystem permissions across platform boundaries, where those were previously flattened to host defaults .
"Keep remote exec commands native to the executor," commit #29099, openai/codex (source: releases.sh changelog).
Two companion changes reinforce that principle:
- Reported-shell execution (#28983): "core: keep remote exec on reported shell" routes commands through the executor's own reported shell instead of the host shell in cross-platform sessions, so a Linux executor stops inheriting a Windows caller's shell semantics .
- Foreign-environment AGENTS.md (#28958): remote sessions now respect executor-native agent configs rather than ignoring them, which matters for teams that keep per-host AGENTS.md setups .
Read together, these are not cosmetic. An agent that silently runs in the host's shell, directory, and permission context can corrupt assumptions a remote box depends on. The 0.142 work makes the remote machine the source of truth for its own execution environment, and wraps the connection so the relay itself can't be read in transit .
SQLite WAL corruption patched: the bundled-fix story
Among the quietest fixes in the 0.142.0 window is a SQLite WAL-reset corruption bug, patched by pinning the bundled SQLite to a fixed version . It is not documented in the alpha release text: the per-tag pages only state "Release 0.142.0-alpha.N" and an asset count . Both the pin and the corruption fix appear only in commit analysis .
The mechanics matter for anyone running Codex hard. WAL (write-ahead logging) mode batches writes to a side log and periodically checkpoints them back into the main database file. A faulty WAL-reset path can corrupt that file precisely when checkpoints fire often, which is exactly the profile of a long-running or tool-heavy session. The agent writes state constantly, so the sessions most likely to trip the bug are the ones developers lean on most.
What the fix does, and does not, require:
- No schema migration. Pinning the bundled SQLite swaps out the faulty version; existing local databases are unaffected by any rewrite step .
- No official advisory. There is no acknowledgment in any release note or in OpenAI's developer changelog, which still highlights 0.141.0 .
- No upgrade signal. Developers moving from the June 18 stable 0.141.0 build will not see this noted anywhere official .
That silence is notable. A data-integrity fix is the kind of change you want flagged clearly, yet it ships invisibly, reinforcing the project's own complaint that release-note discoverability lags its shipping pace .
Cached and time-aware web fetch: how 0.142 differentiates
The 0.142 window stops the model from guessing how fresh its data is. Two merged PRs, "Add indexed web search mode" (#28489) and "Use cached and live web access terminology" (#29095), introduce named fetch tiers instead of implicit recency inference . A caller now distinguishes an indexed/cached lookup from a live fetch, rather than hoping the model decides correctly.
Quick Answer: Codex 0.142 replaces implicit recency guessing with explicit fetch tiers (indexed/cached versus live web), plus a clock current-time tool (#29011), per merged PRs on the main branch . Integrators declare the tier per turn instead of injecting timestamps into the system prompt.
Time awareness is the second half. A clock current-time tool (#29011) with an app-server implementation (#28835) gives the model an explicit way to read the current time . Previously the only route was hand-injecting a timestamp into the system prompt, which was fragile and easy to forget on resume.
| Capability | PR | Before 0.142 |
|---|---|---|
| Indexed/cached fetch tier | #28489 | Implicit, model-inferred recency |
| Cached vs live terminology | #29095 | No named distinction |
| Clock current-time tool | #29011 / #28835 | Manual timestamp injection |
For IDE and app-server integrators, the practical win is control: declare the desired tier per turn rather than betting the model knows whether it needs cached speed or fresh data. That distinction matters for reliable time-sensitive tool chains: without it, a query may hit a stale index when you needed live results, or burn a live fetch when cache would do.
These items are read from commit and PR metadata, not consolidated 0.142.0 notes, which OpenAI had not published as of June 20, 2026 . Confirm the exact tool names against the binary before wiring them into production.
The experimental proactive subagent switch: default off, no knob yet
0.142 also lands a multi-agent routing flag, but it ships dark. The merged "Add per-turn multi-agent mode" PR introduces a turn/start.multiAgentMode field accepting explicitRequestOnly or proactive, gated behind a default-off features.multi_agent_mode feature flag . The PR is explicit about what it does not add: no TUI control, no slash command, no config.toml preference, no concurrency change, no tool-availability change, and no model-catalog change.
"Expose thread-level multi-agent mode" (#28792) extends the same idea to thread creation. It adds an optional, experimental thread/start.multiAgentMode and reports the setting through thread/start, thread/resume, and thread/fork, with specified cold-resume and inherited-thread behavior, still without any interactive surface or config.toml persistence .
This is a routing declaration, not a resource bump. It signals how the model may branch within a turn or thread; it does not promise parallelism, more tools, or extra compute. Concretely, the two PRs leave these untouched:
- Concurrency: no change;
proactiveis not a guarantee of parallel agents. - Tool availability: the same tools remain in scope.
- Model catalog: no new or swapped models.
- Control surface: no slash command, config key, or TUI toggle.
If your integration drives the thread or turn API directly, you can probe this behind the flag today and observe how Codex reports the mode across start, fork, and resume events. Interactive CLI users have no surface for it and won't notice it exists. As with the other items in this article, this reading comes from PR metadata, not consolidated 0.142.0 notes, which OpenAI had not published as of June 20, 2026 . Treat the flag and its values as experimental and verify them against the built binary before depending on them. See the merged per-turn and thread-level PRs for the exact contracts.
Reading 0.142 from commits alone: enterprise fixes and open questions
The clearest 0.142.0 wins for enterprise operators are unglamorous reliability fixes inferred from merged PRs and commit history, not feature headlines. On Windows-hosted executors, the build adds stale-credential auto-repair and gives PowerShell additional grace time before backgrounding, addressing sessions that previously failed as silent hangs and unexplained timeouts . For regulated environments, that turns a class of intermittent failures into something predictable.
Two changes matter specifically for proxied corporate networks. TLS P-521 certificate-signature support lands for enterprise proxies, previously a hard blocker for any org whose proxy chain signs with P-521 curves . Alongside it, Scope network approvals by environment (#28899) and Support protected resource OAuth discovery (#29022) move auth routing from a global posture to a per-environment one .
For developers, the practical implications are:
- Windows executors: fewer mystery timeouts; credential refresh no longer requires a manual restart.
- P-521 proxy shops: a previously unusable setup may now connect; test before rollout.
- Multi-environment teams: network approvals and OAuth discovery can differ per environment instead of one shared rule.
Every item above carries the same caveat. The 0.142.0-alpha note bodies returned "something went wrong" errors on fetch at research time, and aggregator mirrors had not indexed any 0.142 alpha body as of June 20, 2026 . The findings here are read from PR descriptions and commits, not official release text.
The project itself flags the gap. A repo issue asks for "published changelogs, prerelease notes, docs sync, and migration examples" (openai/codex issue #21682 ), an acknowledgment that note discoverability lags shipping pace.
0.142.0 looks like a solid maintenance release for Windows and enterprise users, but it is still a moving alpha with no consolidated notes. Pin a specific alpha tag, verify the fix you care about against the built binary, and wait for the stable 0.142.0 cut before depending on it in production .
Frequently asked questions
How do I install the Codex 0.142 alpha right now?
Opt into the prerelease channel with npm install -g @openai/codex@alpha, or download the tagged binary directly from the GitHub releases page under rust-v0.142.0-alpha.6 . Stable-channel users stay on 0.141.0 automatically and need no action to avoid the alpha .
Why did six alpha builds ship in under 48 hours?
Six rust-v0.142.0 alphas landed between June 18 and June 19, 2026 . This is a rapid CI/CD iteration pattern: each alpha may be a genuine feature increment, a build re-cut, or a patch of the previous one. Without readable release notes, per-alpha attribution is unconfirmed. GitHub issue #21682 calls out this discoverability gap directly .
Is the experimental subagent mode safe to enable in production?
No. The multi-agent mode is default-off behind the features.multi_agent_mode gate, with no TUI control, no slash command, no config.toml persistence, and no documented concurrency limits: it is exposed only at the API layer via turn/start.multiAgentMode . Treat it as internal exploration until it graduates from the feature gate with documented guarantees.
Does the SQLite WAL fix require a database migration?
No. The fix silently pins the bundled SQLite version to resolve a WAL-reset corruption bug; existing databases are unaffected structurally . Upgrade normally: there is no schema migration to run.
When does 0.142 stable ship?
No date has been announced. As of June 20, 2026, version 0.141.0 is still marked Latest on the GitHub releases page and in OpenAI's developer changelog . Watch both for the consolidated stable 0.142.0 tag and notes.
