Release OpenEnv 0.5.0

[cursor]

Release PR: v0.5.0

Planned release: Thursday, September 17, 2026 at 10:00 Europe/Brussels (08:00 UTC) — currently held, see Outstanding blockers.

Candidate head: 34825a77 (main tip at the time of writing). 47 commits since v0.4.2.

Why 0.5.0 and not 0.4.3: this cut adds new public surface — the openenv.harbor package, the RFC 011 openenv catalog / openenv discover commands, the RFC 008 validate contracts — plus a new environment. A patch number would misrepresent it. A true 0.4.3 would require reverting those features through review. The version line is a one-line edit if you want a different number.

Release notes

• Harbor integration: serve Harbor task datasets through OpenEnv as trainable environments, with a transparent capture proxy for token-faithful traces (#1036).
• Versioned environment discovery (RFC 011): metadata-only openenv catalog and openenv discover, packaged environment-card schemas, authored discovery declarations, and a catalog artifact workflow (#1138, #1093, #1161, #1167).
• Environment validation contracts (RFC 008): restored manifest and validation contracts, the openenv validate skeleton, and schema-valid scaffolds (#1110, #1111, #1112, #1137).
• ThinkingBox environment: new reasoning-benchmark environment, docs, dedicated CI, and evaluator-failure isolation (#1092, #1141).
• Production MCP mode: route production MCP through JSON-RPC over a shared session, and fix Gradio Playground MCP argument parsing (#1169, #1175, #1081).
• Client and WebSocket reliability: drop the socket on receive timeout, cancel-safe EnvClient teardown, reconnect after a far-end close, and per-user discovery cache paths that reject control characters (#1162, #1172, #1167).
• Correctness fixes: reject corrupt collect resume files, read reward and done from the step envelope in typed clients, and declare importable manifest app paths (#1171, #1017, #1164).
• Dependencies and docs: Tornado, NLTK, and doc-builder updates, a non-mutating lint hook, Environment Builder client docs, sidebar/catalog doc-sync coverage, and Nebius added as a supporter (#1163, #1166, #1165, #1128).

Full candidate comparison: v0.4.2...34825a7

Release-maintenance changes in this PR

• Change 0.4.3.dev0 to stable 0.5.0. Nothing else.

Outstanding blockers

• Capture proxy is unauthenticated on a public default path (from #1036). run_batch() defaults to expose="gradio", which publishes the capture proxy through a public tunnel, but it constructs CaptureServer(...) without admin_key (src/openenv/harbor/runner.py:97). With no admin key, _admin_ok() returns True for every caller (src/openenv/core/harness/capture/server.py:698), so GET /sessions, GET /sessions/{id}/rollout, DELETE /sessions/{id}, and POST /sessions are open — exactly the enumeration, token-level trace disclosure, session deletion, and key-minting relay that the function's own docstring says the key exists to prevent. harbor serve/push set the key correctly (src/openenv/harbor/serving.py:83); run_batch and the standalone python -m openenv.core.harness.capture.server CLI (no --admin-key flag) do not. openenv.harbor and openenv.core.harness.capture are both shipped by setuptools.packages.find, so this reaches PyPI users. Needs a fix, a revert, or an explicit accepted-risk decision before publication.
• Version decision. Confirm 0.5.0 (recommended) or state what should be reverted for a true patch.
• #1169 residuals. The pending-close reattachment race and the RFC 003 agent/orchestration capability question are unresolved; accept for 0.5.0 or resolve first.
• Dispatch and pass publish-testpypi.yml from this exact branch with a unique 0.5.0 pre/dev suffix.
• Reconcile main immediately before merge; rerun all required checks if the head or base changes.

Lower severity, not release-gating on its own: _ContextEnviron.__delitem__ deletes only from the base mapping (src/openenv/harbor/proc_env_context.py:98), so pop("OVERLAY_ONLY", default) raises KeyError despite the default and clear() leaves overlay keys behind while emptying real process environment keys.

Excluded from this candidate: #1145, #1174, #1187, #1189, and #1008 — none is exact-head green with the reviews its content requires. #1173 (envs lockfile security bumps) touches only envs/**/uv.lock and does not affect the published package either way.

Release Checklist

Before opening this PR

• pyproject.toml version changed from 0.4.3.dev0 → 0.5.0
• hf-staging/ is NOT in this PR's diff
• No print(), breakpoint(), or TODO added to release-critical paths
• Release notes include user-facing changes and linked PRs

CI gates (must be green before merge)

• test passes on Python 3.11
• test passes on Python 3.12
• lint passes (usort + ruff)
• Package CI builds, checks, and smoke-tests wheel/sdist installs

TestPyPI validation (before merging)

• Manual dispatch of publish-testpypi.yml from this branch
• TestPyPI published a unique pre/dev version such as 0.5.0.devN
• Verified pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ openenv==0.5.0.devN

Post-merge steps

• Tag v0.5.0 pushed against the exact merge commit
• publish-pypi.yml completed successfully from the tag
• GitHub Release created by the successful PyPI publish workflow
• pip install openenv==0.5.0 from production PyPI verified (import, __version__, CLI, real Echo reset/step)
• Next development-version bump PR opened (the publish workflow cannot open it itself; GitHub Actions is not permitted to create PRs in this repo)

RFC Status

• Not required (release maintenance)

  

---

Note

Low Risk
Single-line version metadata change with no runtime or dependency edits in this diff.

Overview
Bumps the published openenv package version from 0.4.3.dev0 to stable 0.5.0 in pyproject.toml. This is the only code change in the PR; it aligns wheels/sdist and importlib.metadata / openenv.__version__ with the 0.5.0 release cut described in the release notes (Harbor, catalog/discover, validate, etc. are already on the candidate branch, not introduced here).

^{Reviewed by Cursor Bugbot for commit cbe0808. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Stale comment

Alignment Review Report

Scope: this PR is a single-line release bump — pyproject.toml version 0.4.3.dev0 → 0.5.0 (no other files changed).

Automated Checks

• Lint: NOT RUN in sandbox / N/A to diff. uv isn't available in this review environment, so .claude/hooks/lint.sh couldn't execute. The diff changes only a TOML version string (no Python under src//tests/), so it is lint-irrelevant. I verified independently that pyproject.toml still parses as valid TOML with project.version == "0.5.0".
• Debug code: CLEAN (for this diff). check-debug.sh reported pre-existing print()/TODO items (e.g. src/openenv/core/mcp_client.py, core/containers/runtime/providers.py — mostly docstring examples), but none are in this PR's diff, so nothing is attributable to this change.

Open RFCs Context

• Draft: RFC 010 (ECHO token world model), RFC 011 (ARD catalog discovery, @thegovind).
• In Review: RFC 000/001/002/003/005, RFC 008 (auto-validation, @zkwentz), RFC 012 (Harbor capture providers, @adithya-s-k).
• Relevant here: 0.5.0 packages already-merged work tied to these non-final RFCs — RFC 011 discovery (#1138), RFC 012 Harbor (#1036, openenv.harbor), RFC 008 validate contracts.

Tier 1: Fixes Required

None. The version bump is valid TOML and introduces no lint/debug/syntax/type/import/security issues.

Tier 2: Alignment Discussion

Principle Conflicts

None identified. A packaging version bump touches no API signature, client/server boundary, reward path, or MCP/WebSocket interface — no INVARIANTS/PRINCIPLES surface is affected.

RFC Conflicts

ALIGNMENT FLAG: Cutting a stable 0.5.0 that publishes public surface governed by non-final RFCs

• Principle/RFC at stake: INVARIANTS "Breaking Change Policy → Pre-1.0" (authored by @Darktex); RFC 011 (Draft), RFC 008 (In Review), RFC 012 (In Review)
• The concern: The commit message notes 0.5.0 adds new public surface — openenv.harbor, the RFC 011 catalog/discover CLI, and the RFC 008 validate contracts — shipped as a stable (non-rc) PyPI release while those RFCs are still Draft/In Review. Pre-1.0 policy explicitly permits breaking changes if documented in release notes, so this is acceptable, not a blocker — but the team may want to (a) consider an rc pre-release for those surfaces, and/or (b) ensure the auto-generated GitHub release notes mark them as provisional/subject-to-change so downstream consumers aren't surprised when the RFCs finalize.
• Suggested reviewer: @Darktex (semver / breaking-change policy owner), @thegovind (RFC 011), @zkwentz (RFC 008), @adithya-s-k (RFC 012)

Observations (non-blocking)

• Minor-bump intent verified. The post-release dev marker was 0.4.3.dev0, but this cuts 0.5.0 (minor, not patch). The commit message documents the rationale (47 commits since v0.4.2 add new public surface + a new env → minor). This is consistent with .github/workflows/publish-pypi.yml, which accepts any vX.Y.Z tag, hard-gates tag == pyproject.toml version, and auto-opens the next .dev0 bump PR post-publish. No concern.
• Release mechanics reminder. This PR only bumps pyproject.toml. Actual publishing requires pushing tag v0.5.0 on main after merge — that triggers PyPI publish, the GitHub release, and the automated 0.5.1.dev0 post-release bump PR.
• Pre-existing, outside diff: src/openenv/cli/__init__.py hardcodes __version__ = "0.1.0". It appears unused (skills.py imports the dynamic package-level openenv.__version__, which resolves from metadata → 0.5.0), so it won't affect the release, but consider aligning or removing it in a follow-up.

Summary

• 0 mechanical issues to fix (Tier 1)
• 1 alignment point for human review (soft, non-blocking)
• 0 hard RFC conflicts (1 discussion flag)

No blockers found. Not approving/merging — this is an advisory alignment review only.

  

_{Sent by Cursor Automation: Pre-review}

[cursor]

Candidate refreshed: branch head is now 5937a6cf, which is current main 4a1fa2a8 plus the one-line version change. (I cannot edit the PR description — updatePullRequest returns 403 for this integration — so the "Candidate head: 34825a77" line in the body above is stale by one commit: #1173, the envs lockfile security rollup, merged as 4a1fa2a8. It touches only envs/**/uv.lock and does not change the published package.) The cut is now 48 commits since v0.4.2.

CI gates on this exact head: test (3.11), test (3.12), lint, Build and smoke-test package, Analyze (python), snapshot, check-env-docs, validate-env-locks, both ThinkingBox jobs, and Bugbot all pass on the pre-refresh head aab0e319; they are rerunning on 5937a6cf.

I am not merging this and not publishing today. The blockers in the description are unresolved — above all the capture proxy shipping without an admin key on run_batch()'s default public expose="gradio" path, which would reach PyPI users. TestPyPI has deliberately not been dispatched: validating a candidate that is held on a security finding would only produce a misleading green. Production PyPI and the GitHub release both remain 0.4.2.

What I need to proceed: the version confirmation (0.5.0 as written, or a stated rollback for a true patch), and a fix, revert, or explicit accepted-risk decision on the capture-proxy auth finding. Once those land I will refresh onto main, rerun every gate on the exact head, dispatch TestPyPI, and only then merge, tag, and publish.

View PR

  

_{Sent by Cursor Automation: Release}

[cursor]

Version decision from @burtenshaw: go with 0.5.0 as written. No rollback to a patch.

Capture-proxy finding: a forward-fix PR is being opened now (mint an admin key in run_batch() and add --admin-key to the standalone capture server CLI); it will be linked here once it is up and @adithya-s-k has been asked to review it.

[cursor]

Forward-fix for the capture-proxy admin-key finding: #1193. Review requested from @adithya-s-k. Once it merges, this candidate should be refreshed onto main (which now also includes #1174, #1192, and the finqa fix from #1008) and the gates rerun.

[cursor]

Alignment Review Report

Scope: This is the OpenEnv 0.5.0 release PR. The entire change is a single line in pyproject.toml (version = "0.4.3.dev0" → "0.5.0"); git diff against both main and the merge-base confirms nothing else changed. Findings below are verified against the repo's actual CI. (Note: this PR is already merged — posting for the record.)

Automated Checks

• Lint: PASS (CI-verified). The lint check on this PR is green, and I reproduced it locally: ruff check src/ tests/ → "All checks passed!", and the CI format pipeline (usort format then ruff format src/ tests/) yields no net change.
  • The local .claude/hooks/lint.sh reports FAIL, but this is entirely pre-existing and outside CI's scope — unrelated to this diff:
    • usort check flags tests/envs/test_grid_world.py and tests/envs/test_julia_env.py (one blank-line-after-import each) — the two files already documented in AGENTS.md. usort-alone disagrees, but the combined CI pipeline (usort → ruff format) reconciles to a no-op, which is why CI stays green. Unchanged since #895 (Jul 2026).
    • ruff format --check envs/ flags 56 files, but CI only formats src/ tests/; the local hook additionally lints envs/.
  • The diff itself (a TOML version string) introduces zero lint issues.
• Debug code: CLEAN (w.r.t. diff). check-debug.sh surfaces only pre-existing docstring print(...) examples, Rich console.print, and deferred-feature TODOs in src/; no breakpoint()/pdb. None are in this diff.

Open RFCs Context

In Review: 000, 001, 002, 003, 005, 008, 012 (Harbor capture providers). Draft: 010, 011. A version-string bump implements no design surface, so none of these RFCs are affected or pre-empted.

Tier 1: Fixes Required

None. The one-line bump has no mechanical issues:

• 0.5.0 is valid PEP 440, and the publish-pypi workflow's guard (release tag vX.Y.Z must equal the pyproject version and be a stable release) is satisfied — this bump is exactly what enables a clean v0.5.0 tag.
• openenv.__version__ resolves dynamically via _load_package_version() from installed metadata, so no code needs updating to match.
• The hardcoded __version__ = "0.1.0" in src/openenv/cli/__init__.py is stale, but it is unused (not imported or wired to any --version flag) and pre-existing — out of scope for this PR.

Tier 2: Alignment Discussion

Principle Conflicts

None identified. There is no functional change, so nothing touches rewards-in-environment, client/server separation, the dual API boundary, or the Gymnasium reset/step/state signatures.

RFC Conflicts

None identified.

Process note (non-blocking)

ALIGNMENT FLAG: Minor-version release without in-repo release notes

• Principle/RFC at stake: INVARIANTS "Breaking Change Policy" / PRINCIPLES pre-1.0 versioning
• The concern: The policy states pre-1.0 breaking changes are "acceptable if documented in release notes." This is a MINOR bump (0.4.x → 0.5.0) covering 59 commits since v0.4.2, including the Harbor integration (#1036), yet there is no CHANGELOG in-repo. Recommend confirming the v0.5.0 GitHub Release carries notes. Also a quick confirm that 0.5.0 is intended rather than 0.4.3 (which the prior 0.4.3.dev0 marker implied) — since MINOR is the correct bucket for new features (PATCH is "bug fixes only"), 0.5.0 looks like the right call.
• Suggested reviewer: @Darktex (author of the Breaking Change Policy lines in INVARIANTS.md / PRINCIPLES.md)

Summary

• 0 mechanical issues to fix
• 1 low-priority process note for human review (release notes + version-intent confirmation)
• 0 RFC conflicts

  

_{Sent by Cursor Automation: Pre-review}