ConnectOnionRelease Channels
Stable 1.7, completed candidate status, and the independent 1.8 preview stay explicit.
Current stable
v1.7.0
Installed by normal pip commands.
Release candidate
No active candidate
Stable 1.7 has completed its candidate window.
Latest preview
v1.8.0a2
Available only to users who explicitly opt in.
Stable 1.7 design
A Work Room is a client, not a status panel
OIP gives the browser one session boundary while native Codex and Claude Code keep their own conversation, lifecycle, permissions, and follow-up semantics.
A version is a compatibility promise, not a progress counter.
A version such as 1.6.3 maintains stable 1.6. New 1.7 features are tested as 1.7.0aN, 1.7.0bN, and 1.7.0rcN before 1.7.0 becomes stable.
Alpha
X.Y.ZaNIncomplete, usable slices for opt-in developers. Interfaces may still change.
Beta
X.Y.ZbNFeature-complete. Testing shifts to integration, upgrades, compatibility, and real users.
Release candidate
X.Y.ZrcNCould become stable unchanged. Only release-blocking fixes are accepted.
Stable / LTS
X.Y.ZDefault for normal installs. New features move to 1.8; 1.7.x receives maintenance fixes.
Install stable
Normal installs and upgrades ignore preview releases. Publishing a preview does not move existing users off stable.
Install exact stable 1.7
Use the exact pin for a reproducible 1.7 installation. A broad --pre upgrade follows the highest published feature train, which is currently 1.8.0a2, not Stable 1.7.
Join the preview track
The --pre flag is the explicit opt-in. An exact pin such as connectonion==1.8.0a2 also opts in and does not need --pre.
Current plan
1.6.x: previous stable maintenance line.
1.7.x: current stable/LTS maintenance line.
1.8.0 previews: new remote-browser sessions and hosted execution after the 1.7 gates close.
Track the live scope in the 1.7 milestone and the exact PR inventory and phase gates in issue #792.
How a candidate earns promotion
Each release gate starts from the exact published package, launches its real co ai Host, and connects the production O Chat build through a real browser. The acceptance flow exercises a deterministic catalog search and attachment download through co browser, C, C++, and Rust projects, native Codex delegation, permission modes, cancellation, Host restart, and reconnect without resending the last prompt.
The run produces screenshots, sanitized logs, and a hash-addressed manifest. UI text alone cannot mark the gate as passed: process state, workspace output, reconnect state, and the absence of a duplicate input are checked independently. A failed gate stays failed and feeds the next issue and PR.
Backend promotion also collects the complete mocked oo-api test tree. Integration and live-provider cases stay explicit, but a new billing or API contract test cannot sit outside CI just because it was added in a separate test module.
Stable outcome: the accepted RC12 product source completed the exact installed-artifact gate and became 1.7.0. The coordinated browser reader is @connectonion/react@0.4.3; O Chat owns presentation rather than parsing provider-private streams.
Claude Code and Codex preserve their provider session IDs, stream normalized tool activity through OIP, and appear as live cards in O Chat through @connectonion/react.
The public wheel denied an outside-workspace write in headless Auto and left its target absent; explicit bounded Full access then completed the outside canary read and write plus the full Todo lifecycle.
A running coding task now streams compact, correlated provider activity and its nested approval into one Work Room. That Work Room remains a real remote Codex or Claude Code client: attributed user and provider messages and the provider-targeted composer stay visible through running, approval, Stop, reconnect, and completion. Temporarily unavailable input is disabled with a reason, not removed. Recent semantic steps stay readable; raw commands and outputs are opt-in details.
Descriptor-less OIP 0.1 peers remain readable through 1.7.x. Unsupported versions fail once without reconnecting, and privacy-safe compatibility telemetry contains no prompts, identities, or paths.
Design Journal
Why the preview train uses alpha, beta, and RC
Release notes explain what changed. The design journal explains why OIP owns the browser boundary, while a Work Room treats one long native coding task as a live, correlated surface rather than a terminal transcript.
Read the Work Room decision