Release OpenEnv 0.6.1

[cursor]

Release PR: v0.6.1

Planned release: Thursday, October 1, 2026 at 10:00 Europe/Brussels (08:00 UTC).

Candidate base: 9e0fd9ba (main tip). 3 commits since v0.6.0. This is the rolling release PR for the week and will be refreshed onto the final candidate head before merge.

Version: 0.6.1, and no decision is needed. Unlike 0.6.0 this week adds no public surface — one bug fix plus an internal refactor whose declared API is unchanged (evidence below). That is a patch under the same standard used for 0.5.0 and 0.6.0.

Release notes

• Novita Dockerfile ARG substitution no longer corrupts FROM: ARG BASE declared before ARG BASE_IMAGE used to rewrite FROM $BASE_IMAGE to python:3.12_IMAGE, because defaults were substituted name by name. Substitution is now longest-name-first, so declaration order no longer matters (#1235).

Not in the wheel, but shipped to the repo this week:

• The novita_tbench2_simple example now waits for readiness inside its try, so a readiness timeout stops the paid sandbox instead of leaking it, and a new parse-level test asserts that invariant for every examples/novita_*.py (#1235).
• openenv.core.harness is now a package, with the rollout implementation moved to openenv.core.harness.rollout (#1097).

API compatibility of the harness split

Checked rather than assumed, by installing openenv==0.6.0 and this candidate's wheel side by side and diffing openenv.core.harness:

• __all__ is identical in both: the same 20 declared names.
• 21 names stopped leaking from the module: incidental imports (ABC, Any, Callable, Generic, Protocol, TypeVar, TypedDict, abstractmethod, annotations, dataclass, field, json, math, runtime_checkable) and seven types that were never declared there — JsonRpcErrorCode, JsonRpcResponse, Tool (canonical home openenv.core.env_server.mcp_types), State (…env_server.interfaces), StepResult (openenv.core.client_types), plus LLMResponse and SessionT. All seven remain importable from openenv.core.harness.rollout.

So nothing in the declared API moved. Anyone who relied on an undeclared transitive import such as from openenv.core.harness import json is affected; that seems acceptable for a patch, but say so if you disagree and I will restore the re-exports instead.

Full candidate comparison: v0.6.0...9e0fd9b

Release-maintenance changes in this PR

• 0.6.1.dev0 → 0.6.1 in pyproject.toml, plus the matching editable-openenv pin in envs/grid_world_env/uv.lock and tests/validation_runtime/uv.lock (the only two locks that track the current version; without them validate-env-locks fails).

Outstanding blockers

• Dispatch and pass TestPyPI from this exact branch. workflow_dispatch is 403 for the release token, so this goes through a testpypi/0.6.1 branch carrying the push: trigger, as for 0.5.0 and 0.6.0.
• Reconcile main immediately before merge and rerun required checks if the head moves.

Not in this candidate: #1181 (Level 2 runtime probes, still awaiting zkwentz), #1098–#1100 (approval-gated CI plus open findings), and the fork PRs that still cannot run repository CI. #1222 (FastMCP 4) stays blocked: v4 keys session state by ctx.session_id and our server-side connection is rebuilt per call, so that is a scheduled migration rather than a cap bump.

Local verification already done

• uv sync --frozen --all-groups --all-extras --dry-run --no-install-project passes in both touched lock directories (the validate-env-locks command).
• Wheel and sdist build clean; a fresh 3.11 venv installs the wheel and reports 0.6.1 for both importlib.metadata and openenv.__version__, and openenv --help works.

Release Checklist

Before opening this PR

• pyproject.toml version changed from 0.6.1.dev0 → 0.6.1
• 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)

• 0.6.1.devN published from this candidate head
• Published wheel byte-compared against a local build of the same head
• Fresh-venv install, imports, CLI, and a real Echo reset/step smoke

Post-merge steps

• Tag v0.6.1 against the exact merge commit on main
• publish-pypi.yml completed (expect Open post-release bump PR to fail — GitHub Actions cannot create PRs in this org; open it by hand)
• GitHub Release created, assets byte-identical to PyPI
• pip install openenv==0.6.1 verified from production PyPI
• Next development-version bump PR opened and processed

RFC Status

• Not required (release maintenance)

  

---

Note

Low Risk
Version and lockfile-only changes with no runtime logic modified in this diff.

Overview
Bumps the openenv package version from 0.6.1.dev0 to 0.7.0 in pyproject.toml and keeps the editable dependency pins in sync in envs/grid_world_env/uv.lock and tests/validation_runtime/uv.lock so lock validation (validate-env-locks) stays green.

No application or API code changes appear in this diff—only release metadata and lockfile entries for the local openenv package.

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

[cursor]

Stale comment

Release status: refreshed 2026-09-30 06:25 UTC (supersedes earlier notes)

Candidate head 9eab9d93 = main 4f4c85fb + three version lines. Planned release: Thursday 1 Oct 2026, 08:00 Brussels (06:00 UTC run). The PR title/body still say 0.6.1 and 10:00; this comment is authoritative.

Version changed 0.6.1 -> 0.7.0 (decision needed from Ben; this is my default)

Since the last refresh, main gained RFC 005 public API: #1098 (turn-based agentic harness types: HarnessEnvironment, AgenticHarnessAdapter, HarnessProcess, events, MCP bridge; 18 new names in openenv.core.harness.__all__, 20 -> 38) and #1100 (production /harness WebSocket route; create_app(..., mode=) plus OPENENV_MODE now honored by create_fastapi_app). New public surface is a minor bump under the standard used for 0.5.0 and 0.6.0. A true 0.6.1 would need a reviewed rollback. If Ben prefers 0.6.1, revert the three version lines and re-run TestPyPI.

Release notes (draft)

• Added: RFC 005 turn-based agentic harness API in openenv.core.harness (#1098) and the production /harness WebSocket route for harness environments (#1100). create_app/create_fastapi_app accept mode= and read OPENENV_MODE (default stays simulation).
• Fixed: Novita Dockerfile ARG substitution no longer corrupts FROM; the novita_tbench2_simple example stops its sandbox on readiness timeout (#1235).
• Refactor: openenv.core.harness is now a package; declared API unchanged (#1097).
• Repo only: governance doc (#1261), justfile (#1096), Harbor docs rendering (#1272).

Full comparison: v0.6.0...9eab9d9

Review of what landed on main since the last candidate

• Main CI on 4f4c85fb is green except the known nightly sync-global-collection (missing HF_TOKEN), not a release gate. #1098/#1100 merged by burtenshaw with approval and no unresolved review threads.
• No release blocker found. Non-blocking observation: for non-class env factories, _factory_produces_harness_env instantiates the factory once (then close()s it) at route registration in production mode. Cheap for most envs, but heavy factories pay a startup cost.
• #1099 (approved, bounds HarnessMCPBridge.stop() with an open stream) is not in the candidate; it needs Approve-and-run for fork CI. Recommendation: ship 0.7.0 without it and follow with a patch.

Evidence at 9eab9d93

• Exact-head CI: 12/12 pass (test 3.11/3.12, thinkingbox x2, lint, package build/smoke, Linux Docker runtime validation, validate-env-locks, CodeQL, env docs, snapshot); merge state CLEAN.
• Local: 3167 passed / 103 skipped (CI selection); ruff format/ruff check clean, usort flags only the two known pre-existing files; uv build + twine check pass; py3.11 wheel and py3.12 sdist clean installs report 0.7.0 with CLI and all 38 harness.__all__ names importable; real Echo reset/list_tools/step/state smoke passes.
• TestPyPI 0.7.0.dev171 (run 36677362101, from testpypi/0.7.0 @ bd722ca3 = candidate + scratch-only workflow commit; serialized behind automation-locks/openenv-release-0.7.0, released). Wheel sha256 f3338150cd7e27a63c46e18806a2e276c497ae1d2c1586e2ca71e87bc5123d4f; all 174 packaged openenv/** files are byte-identical to a local build of the candidate. Fresh 3.11 install with [novita] from that artifact: version, imports, CLI and Echo smoke pass.

Still to do on Thursday

• Refresh onto main immediately before merge; re-run CI, and TestPyPI only if package bytes change.
• Mark ready, merge (exact-head guard), tag v0.7.0 on the merge commit, run publish-pypi.yml.
• Verify fresh production PyPI install, GitHub release assets, then open the 0.7.1.dev0 bump PR by hand (the workflow's bump job cannot create PRs in this org).
• Version decision from Ben (above).

  

_{Sent by Cursor Automation: Release}

[cursor]

Stale comment

The branch now says 0.7.0 but this description still says 0.6.1 throughout, and two of its claims are now false. I wrote that text on Monday when the week really was a patch; #1098 and #1100 have landed since. This is the same failure mode that bit 0.6.0 — notes asserting something the candidate no longer matches — so here is replacement text. I cannot edit the body (403 on updatePullRequest).

Measured, so the notes can state it rather than imply it: installing openenv==0.6.0 and this candidate's wheel side by side, openenv.core.harness.__all__ goes from 20 to 38 names, with none removed. Added: AgenticHarnessAdapter, HarnessAction, HarnessClientMessage, HarnessConfig, HarnessEnvironment, HarnessError, HarnessEvent, HarnessEventType, HarnessMCPBridge, HarnessNotRunningError, HarnessProcess, HarnessResponse, HarnessStartupError, HarnessTransport, HarnessTurnTimeoutError, build_bridge_server, events_to_metadata, resolve_tool_conflicts. That is unambiguous new public API, so 0.7.0 is correct and additive.

Replace the header paragraph

Version: 0.7.0. src/openenv/ gains 2,548 lines across 13 files since v0.6.0, including the RFC 005 harness surface — 18 new exported names in openenv.core.harness and the production /harness WebSocket route. New public API is a minor bump under the same standard used for 0.5.0 and 0.6.0; a 0.6.1 patch would need a reviewed rollback of #1098 and #1100.

Replace the release-notes list

- **RFC 005 agentic harnesses:** `HarnessEnvironment` plus the foundation types
  (`HarnessConfig`, `HarnessAction`/`HarnessResponse`, `HarnessEvent`/`HarnessEventType`,
  the `HarnessError` family), the subprocess helper `HarnessProcess`, the MCP tool bridge
  (`HarnessMCPBridge`, `build_bridge_server`, `resolve_tool_conflicts`) and the production
  `/harness` WebSocket route with mode wiring
  ([#1098](https://github.com/huggingface/OpenEnv/pull/1098), [#1100](https://github.com/huggingface/OpenEnv/pull/1100)).
  `openenv.core.harness.__all__` grows from 20 to 38 names; nothing was removed.
- **`openenv.core.harness` is now a package,** with the rollout implementation in
  `openenv.core.harness.rollout` ([#1097](https://github.com/huggingface/OpenEnv/pull/1097)).
  Verified API-compatible: `__all__` was unchanged by that split, and only undeclared
  transitive imports (`json`, `math`, typing helpers, and types whose canonical homes are
  `openenv.core.env_server.mcp_types`, `…interfaces` and `openenv.core.client_types`)
  stopped leaking from the module.
- **Novita Dockerfile `ARG` substitution no longer corrupts `FROM`:** `ARG BASE` declared
  before `ARG BASE_IMAGE` used to rewrite `FROM $BASE_IMAGE` to `python:3.12_IMAGE`.
  Substitution is now longest-name-first, so declaration order no longer matters
  ([#1235](https://github.com/huggingface/OpenEnv/pull/1235)).

Not in the wheel, but in the repo this week:

- The `novita_tbench2_simple` example waits for readiness inside its `try`, so a timeout
  stops the paid sandbox instead of leaking it, with a parse-level test asserting that for
  every `examples/novita_*.py` ([#1235](https://github.com/huggingface/OpenEnv/pull/1235)).
- A `justfile` for common dev commands ([#1096](https://github.com/huggingface/OpenEnv/pull/1096)),
  governance docs, and two Harbor doc rendering fixes
  ([#1272](https://github.com/huggingface/OpenEnv/pull/1272)).

Delete the stale "not in this candidate" sentence

It currently names #1098–#1100 as excluded. #1098 and #1100 are in the candidate. The accurate remainder is: #1099 (now a bridge-shutdown fix rather than 3/4 of the stack, still open and awaiting fork CI), #1181 (awaiting zkwentz), #1273 (Harbor UI, two reads_environment evasions open), and #1222 (FastMCP 4, a scheduled migration — v4 keys session state by ctx.session_id while our server-side connection is rebuilt per call).

Also stale in the checklist

Every 0.6.1 string: the testpypi/0.6.1 branch name, pip install openenv==0.6.1, and the v0.6.1 tag line. TestPyPI is done at 0.7.0.dev171 (run 36677362101), which I independently confirmed is byte-identical to a local build of this head — 175 packaged entries, zero differences — so those three boxes can be ticked.

State otherwise: 9eab9d93, CLEAN, all checks green, exactly three version lines against main.

View PR

  

_{Sent by Cursor Automation: Release}

[cursor]

Release OpenEnv 0.7.0 — final candidate notes (supersedes the stale 0.6.1 body and earlier notes)

The PR title and body still say 0.6.1, but this PR ships 0.7.0 (pyproject.toml plus both root-pinning locks). gh pr edit is not available to the release token, so these notes replace the body. The merge uses --subject "Release OpenEnv 0.7.0 (#1258)".

Candidate head: 0dc70de7 = main 86a180ed plus the three version lines (diff vs main is exactly pyproject.toml, envs/grid_world_env/uv.lock, tests/validation_runtime/uv.lock). main moved a lot after the previous 9eab9d93 candidate was tested, so I merged it in and re-validated everything below on the new head.

Release notes (since v0.6.0)

New public API / features

• RFC 005 agentic harnesses: foundation types and the production /harness WebSocket route, 18 new names in openenv.core.harness (#1098, #1100); openenv.core.harness is now a package (#1097); MCP bridge shutdown is bounded and live servers are retained (#1099).
• Typed training contract: TrainingTurn, TrainingTrace (openenv.core.harness.training), TrainableSession (openenv.core.harness.rollout) with producer-owned loss masks (#1280).
• Reworked Harbor serve web UI, shipped as new package data openenv/harbor/ui_assets/*; core now requires huggingface_hub>=1.29.0 (#1273).

Fixes

• Novita Dockerfile ARG substitution no longer corrupts FROM; the example no longer leaks a sandbox on readiness timeout (#1235).
• Server Dockerfile template no longer copies the venv twice (#1034).
• Verifier reward hardening: only a reward.txt written during verification is accepted, and any finite reward is accepted (#1200); opencode_env no longer retries the install when version resolution fails (#1074).

Deprecations

• opencode_env and pi_env are deprecated in favour of harbor_env, removal in 0.8.0 (#1276).

Docs / repo

• RFC 006 harness-interception (#941), governance and deprecation policy (#1261, #1277), justfile (#1096), consolidated Dependabot Action bumps (#1271), Harbor docs fixes (#1272).

Compare: v0.6.0...main

Known issues shipping in 0.7.0 (already on main, merged by maintainers; for 0.7.1)

• #1280 training contract: TrainingTrace accepts turns=[] and all-zero masks; native OpenCode never certifies vLLM processed_logprobs; a failed main call plus a successful tool-less title call exports the title as supervised; the Harbor exporter ignores HarborRolloutResult.ok. New public core APIs and the FATAL-to-WARN change are not yet reflected in RFC 006/012.
• #1273 Harbor UI: the generic /mcp route is unauthenticated, so it bypasses the UI's policies and quotas, and run_rollout(llm_url=...) is not SSRF-checked; declared Gradio floors (>=4.0.0) are lower than the first release that runs the UI (6.7). Treat the UI as not hardened for untrusted public deployment.
• Root requires huggingface_hub>=1.29.0, but envs/grid_world_env/uv.lock and tests/validation_runtime/uv.lock still pin older versions, so uv lock --check fails on main as well (frozen dry-run sync passes; not part of the wheel).

Evidence on 0dc70de7

• Required CI: test 3.11/3.12, lint, Package CI, thinkingbox, discovery, docs-check, Analyze all green; Runtime validation / Linux Docker finishing at the time of writing (re-checked immediately before merge). test (3.11) first failed only on a transient itsdangerous download error in Install dependencies; retriggered with an empty commit (identical tree).
• Local: wheel + sdist build, twine check, clean-venv installs (3.11 wheel, 3.12 sdist), openenv --help, harness/training imports, ui_assets (10 files) present in wheel and sdist, 3322 passed / 103 skipped, real Echo reset/list_tools/step/call_tool/state against the installed wheel. usort/ruff match CI (only the known pre-existing README.md code-block format note).
• TestPyPI 0.7.0.dev181 (run 36822940306, scratch testpypi/0.7.0 @ c3e824ba = candidate + workflow trigger only): sha256 matches the index, 192 non-dist-info members byte-identical to a build of the candidate, identical 26 Requires-Dist, clean install + imports + CLI pass. The run's own verify step was red only on TestPyPI index lag (No matching distribution found for 6 minutes after a successful upload), the same false negative seen for 0.6.0.
• Release lock: refs/release-lock/v0.7.0 held by run bc-6d6dc834.

  

_{Sent by Cursor Automation: Release}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 0dc70de. Configure here.}

[cursor]

Wrong version for 0.6.1 release

High Severity

This release is for 0.6.1, but pyproject.toml and the matching lock pins were set to 0.7.0. Tagging v0.6.1 fails the PyPI publish version check, and shipping 0.7.0 would skip the intended patch and consume that PyPI version permanently.

Additional Locations (2)

• envs/grid_world_env/uv.lock#L1227-L1228
• tests/validation_runtime/uv.lock#L915-L916

 

^{Reviewed by Cursor Bugbot for commit 0dc70de. Configure here.}

[cursor]

Alignment Review Report

Automated Checks

• Lint: N/A — uv isn't installed in this sandbox, and this PR's diff doesn't touch any Python source (usort/ruff have nothing to check here anyway: only pyproject.toml + 2 uv.lock files changed).
• Debug code: CLEAN for this diff — check-debug.sh flags pre-existing print()/TODO in src/openenv/harbor/* and src/openenv/core/containers/*, none of which are touched by this PR.

Open RFCs Context

• RFC 005 (Agentic Harness Integration) — status In Review, sole author @Darktex. Directly relevant: sub-PRs 2/4–4/4 (#1098, #1099, #1100 — foundation types, HarnessEnvironment, OpenClaw adapter, production /harness WebSocket route) have already merged to main and are included in this release candidate, even though the RFC itself hasn't been marked Accepted.
• Other RFCs (000–004, 006, 008, 010–012) don't intersect with a pure version-bump diff.

Tier 1: Fixes Required

• pyproject.toml (and PR description) — the version was bumped to 0.7.0, but the PR title ("Release OpenEnv 0.6.1"), branch name (cursor/release-0.6.1), and body ("Version: 0.6.1, and no decision is needed... patch") all still describe a 0.6.1 patch release. These are now mutually inconsistent with the code actually being shipped.
• PR body's compatibility claim is stale: it states __all__ is "identical in both: the same 20 declared names" for openenv.core.harness. On this branch's current src/openenv/core/harness/__init__.py, __all__ has 42 entries, including a new "Turn-based agentic harness API (RFC 005)" block (HarnessEnvironment, AgenticHarnessAdapter, HarnessConfig, HarnessMCPBridge, build_bridge_server, etc.) plus TrainableSession/TrainingTrace/TrainingTurn. This is new public API surface, not a like-for-like refactor.
• PR body's "3 commits since v0.6.0" / "Candidate base: 9e0fd9ba (main tip)" is stale — 9e0fd9ba is the commit for PR #1097 (the harness package split) specifically, not the current main tip. There are actually 81–86 commits between v0.6.0 and this branch's head, including the full RFC 005 2/4–4/4 feature work, not just "one bug fix plus an internal refactor."

Tier 2: Alignment Discussion

Principle Conflicts

ALIGNMENT FLAG: Release is classified as a PATCH while shipping new public API

• Principle/RFC at stake: INVARIANTS.md → Breaking Change Policy ("MINOR: New features, backward compatible" vs "PATCH: Bug fixes only")
• The concern: The commit history on this very branch shows the version was deliberately bumped to 0.7.0 with the message "release: bump candidate to 0.7.0 (new public harness API)" — consistent with the __all__ diff above showing real new public exports. A later merge from main plus a CI-retrigger commit left the code at 0.7.0, but the PR title/body were never updated and still argue for 0.6.1/patch. Shipping 0.7.0's worth of new public API under a 0.6.1 patch narrative would understate the change for anyone diffing release notes, and conflicts with the project's own semver policy that new, backward-compatible features are MINOR, not PATCH.
• Suggested reviewer: @Darktex (authored the Breaking Change Policy section of INVARIANTS.md, and is also sole author of RFC 005 whose new API is the actual driver of this version bump)

RFC Conflicts

ALIGNMENT FLAG: Release ships RFC 005 surface while RFC 005 is still "In Review"

• Principle/RFC at stake: RFC 005 (Agentic Harness Integration), status In Review
• The concern: This release candidate's main merge already includes RFC 005's foundation types, HarnessEnvironment, the OpenClaw adapter, and the production /harness route (PRs #1098–#1100), all newly exported from openenv.core.harness.__all__. Treating this as a routine 0.6.1 patch sidesteps the design-review signal that an "In Review" RFC status is meant to carry — worth a quick confirmation that shipping this surface publicly is intended before the RFC is formally Accepted.
• Suggested reviewer: @Darktex (sole author of RFC 005)

Summary

• 0 mechanical lint/debug issues (diff is version-bump + lockfiles only; hooks found nothing new)
• 3 factual/description-accuracy issues to fix in the PR body before merge (version narrative, __all__ claim, commit-count/base claim)
• 2 alignment points for human review (semver classification vs. Breaking Change Policy; shipping an In-Review RFC's surface under a patch label)

  

_{Sent by Cursor Automation: Pre-review}

[cursor]

This sets the version to 0.7.0, but the PR title/branch/body ("Release OpenEnv 0.6.1", cursor/release-0.6.1, "Version: 0.6.1 ... patch") still describe a 0.6.1 patch release. An earlier commit on this branch (release: bump candidate to 0.7.0 (new public harness API)) deliberately moved to 0.7.0 because main picked up RFC 005's new public harness API (HarnessEnvironment, AgenticHarnessAdapter, etc. — now in openenv.core.harness.__all__, which has grown from 20 to 42 names since v0.6.0). Please reconcile the version with the PR description: either the description needs to catch up to 0.7.0 and its real scope, or there's a deliberate decision to revert to 0.6.1 that should be stated explicitly.