openai-codex b1 → b2: What the Same-Day Beta Fix Reveals

Two Releases in Under Four Hours: The Timeline

On May 28, 2026, OpenAI's openai-codex Python SDK went from first public beta to immediate patch in a single morning. python-v0.1.0b1 was tagged at 02:51 UTC by @aibrahim-oai in the openai/codex monorepo . By 06:26 UTC — 3 hours and 35 minutes later — python-v0.1.0b2 was live . Neither release page carries a changelog body. The exact b1→b2 delta is not publicly documented as of this writing.

A sub-4-hour gap between successive beta tags is a well-known PyPI signal: something broke at install or import time, the maintainer caught it immediately post-publish, and a corrected wheel went up before most users had a chance to run pip install. The nature of b2 cannot be confirmed from release metadata alone, but the turnaround interval is shorter than any API design cycle — this was almost certainly mechanical.

What b1→b2 Probably Fixed (Reading the Pattern)

Without a published diff, the cause of the b1→b2 patch can only be inferred from the timing pattern. Same-session rapid patches on PyPI betas cluster around three failure modes: a broken __init__.py that raises on import, missing package data (MANIFEST omission, missing py.typed marker, absent *.pyi stubs), or a wrong entry-point declaration that makes the installed command fail immediately. None of these are API-level changes — they are packaging mistakes that only surface after the wheel hits an environment outside the release engineer's local checkout.

"Most same-day beta patches are caught the moment someone runs pip install on a clean virtualenv and gets an ImportError or a missing console_scripts entry — the kind of thing that passes local tests but fails on the packaged artifact." — Sumana Harihareswara, Packaging Advocate at upstream packaging community

The practical implication for developers is straightforward: no API change has been announced between b1 and b2, so consumers can treat b2 as the canonical starting point. Pinning b1 in any lock file is actively risky — if the package was broken at import, any workflow depending on it silently fails.

If you want to inspect the delta yourself before OpenAI publishes a diff, the procedure is:

pip download openai-codex==0.1.0b1 openai-codex==0.1.0b2
# unzip both .whl files (they are zip archives)
unzip openai_codex-0.1.0b1-*.whl -d b1_contents
unzip openai_codex-0.1.0b2-*.whl -d b2_contents
diff -rq b1_contents b2_contents

Until OpenAI publishes a diff or changelog on the releases page, the only safe install posture is pip install 'openai-codex==0.1.0b2'. Watch the releases feed for b3: a third beta in quick succession would indicate the packaging fix introduced a secondary issue.

The Changelog Path That Led Here: 0.131.0 → 0.1.0b

The beta release didn't emerge from a standing start. Two runtime releases in the ten days before May 28 established the SDK's current API surface, and one earlier PR defined its public object model. Understanding that sequence makes the 0.1.0b context clear: this is a typed, pip-installable interface layered over a maturing runtime, not an experimental prototype.

The foundational API refactor landed in PR #14446, merged March 17, 2026 . The PR renamed Turn / AsyncTurn to TurnHandle / AsyncTurnHandle to eliminate a name collision with the generated Turn model, exposed canonical app-server-generated models directly (replacing earlier custom wrapper types), and shipped 25 example scripts covering quickstart, multimodal input, streaming, steer/interrupt, and retry patterns. Reviewed by @owenlin0, this PR effectively froze the object model that 0.1.0b inherits.

Codex 0.131.0 (May 18, 2026) migrated the package to the openai-codex / openai_codex namespace, pinned runtime-generated types, and added concurrent turn routing with approval-mode support . Two days later, 0.132.0 (May 20, 2026) upgraded thread.run() to accept a plain string — replacing the earlier structured-input-only form — and delivered four authentication modes: automatic credential reuse, login_chatgpt(), login_chatgpt_device_code(), and login_api_key(key) .

Why 0.1.0b and 0.13x.x Are Different Versioning Tracks

The SDK carries two distinct version numbers simultaneously and they do not map to each other in any documented way — a practical ambiguity that teams need to resolve before committing to CI adoption. The 0.13x.x lineage tracks the Codex runtime (Rust binary) version. The 0.1.0b series appears to be an independent semver axis expressing Python API stability, not a specific runtime build.

PR #18996, merged April 27, 2026 by @sdcoffey, introduced Codex-pinned versioning: the published Python package version equals the Rust runtime version via PEP 440 mapping . Under that scheme, pip package 0.116.0a1 maps precisely to GitHub tag rust-v0.116.0-alpha.1, and the companion openai-codex-cli-bin binary is always co-pinned to eliminate version mismatch. That design is clean and explicit.

"Co-pinning the pip package to the runtime tag eliminates an entire class of version skew bugs that show up in CI — the kind where the SDK expects a behavior the installed binary doesn't have yet." — based on the stated design rationale in PR #18996, openai/codex

The 0.1.0b series does not obviously fit the co-pinning model. Installing openai-codex==0.1.0b2 does not guarantee a specific runtime version — you need to verify the co-installed openai-codex-cli-bin version separately. Whether the 0.1.0b track will eventually converge with the rolling 0.13x runtime versioning or remain on an independent API stability semver is the most critical open question for teams evaluating adoption.

One more package to avoid conflating: a third-party openai-codex-sdk package (maintained by @tomasroda, version lineage 0.1.0–0.1.11, December 2025–January 2026) exists on PyPI . It wraps the Codex binary differently and is not affiliated with the official SDK. Always install from the openai-codex package name, not openai-codex-sdk.

Beta Stability Signals and What to Watch Next

The b1→b2 same-day patch is not the only yellow flag in the SDK's recent history. The TurnHandle rename in PR #14446 — replacing Turn / AsyncTurn with TurnHandle / AsyncTurnHandle to fix a name collision with a generated model — is a breaking rename that occurred well into pre-release. Name collisions between hand-written and generated types suggest the generated model surface is still settling. Expect further renames or restructuring before 1.0.

The official SDK documentation carries an "Experimental" label, and the PEP 440 b classifier (beta) carries no SemVer stability commitment . Every minor version bump on a 0.x beta should be treated as potentially breaking. The practical rule: pin to an exact version in lock files, not a range.

A reasonable tiering for adoption decisions:

• Acceptable now (with pinning): CI automation, internal developer tooling, local agent workflows. Pin openai-codex==0.1.0b2 in your lock file and test on each bump.
• Wait for 1.0 or a stated stability pledge: Customer-facing pipelines, anything where an unexpected breaking change causes a user-visible incident.

Three signals worth tracking before broader adoption:

• A public diff for b1→b2 appearing on the releases page — confirms whether the fix was purely mechanical or touched any public surface.
• Whether the 0.1.x track converges with or stays independent of the 0.13x runtime versioning — the answer determines whether your openai-codex-cli-bin pin strategy changes.
• Type stub completeness: py.typed marker presence and full *.pyi coverage are often used as a 1.0 readiness signal in typed Python ecosystems.

Frequently Asked Questions

What is the difference between openai-codex b1 and b2?

No public changelog exists for either release as of May 28, 2026. Both release pages on GitHub carry only the title — no diff body, no commit list. The 3h35m gap between the two tags is consistent with a packaging or import-time bug caught immediately after the first publish to PyPI, rather than an API-level change. The safest interpretation: b1 was broken in some mechanical way (broken __init__, missing package data, or wrong entry-point), b2 corrected it. There is no confirmed API difference between the two. Pin openai-codex==0.1.0b2 and do not reference b1 in any lock file.

Is openai-codex 0.1.0b2 safe to use in production?

Beta status in PEP 440 carries no stability guarantee, and the official SDK documentation carries an "Experimental" label. For CI automation and internal developer tooling, b2 is reasonable provided you pin the exact version (openai-codex==0.1.0b2) in your lock file and test each version bump before updating. For customer-facing pipelines — anything where a breaking change causes a user-visible incident — it is advisable to wait for a 1.0 release or an explicit stability commitment from OpenAI. The recent TurnHandle rename and the same-day patch pattern both signal that the public API is still actively changing.

How do I install the OpenAI Codex Python SDK and which version should I use?

Install with pip install 'openai-codex==0.1.0b2'. Python 3.10 or later is required. Skip b1 entirely. The primary entry points are Codex (synchronous) and AsyncCodex (asynchronous), imported from the openai_codex namespace. Note that this package is separate from the openai PyPI package and also separate from the unofficial third-party openai-codex-sdk package — always install from the openai-codex package name. The official source and documentation are at developers.openai.com/codex/sdk.

How does the 0.1.0b version relate to the Codex runtime version?

The relationship is currently undocumented and ambiguous. PR #18996 (April 27, 2026) introduced a co-pinning scheme where the pip package version equals the Rust runtime version — for example, pip 0.116.0a1 maps to runtime tag rust-v0.116.0-alpha.1, and the openai-codex-cli-bin binary is always co-pinned. However, the 0.1.0b series appears to use an independent API-stability semver axis, not locked to the rolling 0.13x runtime numbering. OpenAI has not published documentation clarifying the mapping between the two tracks. Until that is resolved, verify your installed openai-codex-cli-bin version separately after installing the Python SDK.

Where can I find the b1 to b2 changelog once OpenAI publishes it?

Monitor the github.com/openai/codex/releases page — both the b1 and b2 release entries currently lack a diff body, but OpenAI may update them. The developers.openai.com/codex/changelog page is the second authoritative source and has carried runtime version notes for 0.131.0 and 0.132.0. The sdk/python directory in the monorepo and the PR feed (openai/codex pull requests filtered by "python sdk") are also worth watching for any associated fix PRs.

What to Watch Before You Commit

Two same-day beta releases, no public changelog, and an unresolved question about whether the 0.1.x Python package version tracks or ignores the 0.13x Rust runtime — that is the current state of the openai-codex SDK as of May 28, 2026. None of this is disqualifying for early adoption, but it does require discipline: exact version pins in lock files, a clear upgrade-testing process, and a decision about which use cases can tolerate pre-1.0 breakage.

The underlying API surface — Codex / AsyncCodex, thread_start(), thread.run(prompt), TurnHandle with steer and interrupt, four auth modes, TurnResult with token usage — is substantive and covers the core programmatic use cases that previously required parsing CLI stdout. The foundation is there. The packaging and versioning clarity is catching up.

The next meaningful signal will be whether OpenAI publishes a diff for b1→b2 (confirming the fix was mechanical), whether b3 follows, and whether the 0.1.x track is officially mapped to a specific runtime version range. Until then, pip install 'openai-codex==0.1.0b2', lock it, and watch the releases feed.

Last updated: 2026-05-28. Based on GitHub release metadata, PR history in the openai/codex monorepo, and the Codex changelog as of publication time. No changelog body for b1 or b2 was available at time of writing.