One Browser Protocol, Native Coding Adapters

ConnectOnion 1.7.0a5 made OIP 0.1 the only first-party browser protocol; alpha.7 closes the raw-provider escape hatch, alpha.10 makes authenticated relay reattach reuse the established session authority, and alpha.11 lets the Host and frontend roll independently inside a bounded compatibility window. The Python Host serves the authenticated /ws boundary, @connectonion/react owns connection and event state, and O Chat renders that state.

Codex and Claude Code are backend adapters. Each preserves its provider session identity and translates bounded native activity into OIP tool events, so the browser has one lifecycle even when the coding provider changes.

What shipped as Stable 1.7

ConnectOnion 1.7.0 promotes the accepted RC12 product source after the complete installed-artifact gate passed. A Work Room is now a remote client rather than a status panel: it keeps attributed user and provider messages, a persistent composer, current Thinking/Working/approval/Stop/reconnect/terminal state, action summaries with technical details collapsed, and the provider's own permission choices inside the outer Host ceiling.

The gate launched the public package's real co ai Host, used an invocation-scoped invite, drove real browser search and download, built strict C11, C++20, and Rust projects, ran native Codex and Claude Code work and provider-scoped Stop, changed permission ceilings, restarted Host, and reconnected without duplicating the last input. Desktop and 390 px layouts were reviewed from hashed evidence. The coordinated reader is @connectonion/react@0.4.3; O Chat remains the presentation layer.

The tradeoff is deliberate: 1.7.0 freezes this compatibility waist. Provider-specific improvements continue in 1.7.1 only when they preserve the public OIP and authority contract; broader remote execution work stays on the 1.8 preview train.

The useful lesson from Happy Coder is to bridge each provider's native session instead of making raw provider transcripts the public wire format. ConnectOnion keeps the parent loop in co ai, drives Codex through app-server and Claude Code through headless stream-json, and translates only bounded activity at the adapter edge. Provider transcripts stay local.

The problem

The earlier preview explored overlapping protocol layers. That duplicated discovery, session, approval, resume, error, and frontend state, and allowed fallback behavior to hide missing executables behind an unhelpful file-not-found error.

Alternatives considered

• Keep both browser transports and synchronize them.
• Force every coding provider through one generic child-agent implementation.
• Use one browser protocol with provider-native backend adapters.

Decision

OIP owns browser connection, onboarding, messages, tool cards, cancellation, and reconnect. codex and claude_code own launch, native events, approvals, sandboxing, and exact resume. Missing providers fail with a direct installation/configuration message; there is no generic fallback.

Intent is part of that boundary. Explicit run/use/start/open Codex requests call codex(); an interceptor rejects executable Codex commands inside shell chains and background/package wrappers before approval or process creation. Commands that merely search for or discuss Codex remain ordinary shell work.

An open request with no task creates or resumes the native Codex thread but sends no turn/start. The Work Room can therefore be real before work begins, without spending a model turn or inventing a prompt.

The browser contract stays small: one correlated provider invocation, OIP tool_call/tool_result activity, the ordinary approval_needed path, and a completed, failed, or cancelled terminal state. The existing React/O Chat cards render that contract without provider-specific wire parsers.

Rolling out one side at a time

One protocol does not mean one atomic deployment. A browser can hold yesterday's JavaScript while a Host has already upgraded, and a frontend rollback can meet sessions written by the newer Host. Requiring a matched pair merely turns ordinary deployment timing into a reconnect outage.

OIP now uses reader-before-writer. Release R reads both the old and new form; R+1 may emit the new form only after R is publicly pinned; removal waits until at least R+2 and 30 days. Descriptor-less OIP 0.1 peers remain accepted through 1.7.x and cannot be removed before 1.8.0a1, September 15, 2026, and two preview releases after compatibility telemetry stops seeing them.

That compatibility is intentionally narrow. Additive, non-authoritative fields can be ignored. Identity, session ownership, protocol version, permission profile, approvals, cancellation, and terminal state are never guessed. An unsupported version receives one non-retryable error instead of an automatic reconnect loop.

The Host records only a classified compatibility result: Direct or Relay, legacy or OIP 0.1 or unsupported, accepted or rejected. It does not copy peer strings, prompts, credentials, addresses, session IDs, or private paths into telemetry.

Tradeoffs and evidence

A small amount of adapter translation is provider-specific, but the authority boundary stays explicit. Release acceptance covers Codex cards in running, completed, failed, expanded, and mobile states; old/new and rollback OIP pairs over Direct and Relay; session resume; raw-launch and false-positive routing evaluations; open-without-turn; and a real published-package browser run.

The published-package run is an evidence boundary of its own. It starts the exact candidate's co ai Host and the production O Chat build, then uses a real browser to exercise a non-trivial project, permission modes, cancellation, Host restart, and reconnect without duplicate input. Screenshots, sanitized logs, and a hash-addressed manifest preserve what ran; UI prose cannot declare the run successful on its own.

What would make us revisit this

We would reconsider only if a provider-neutral interface demonstrates equivalent approval, cancellation, resume, and observability guarantees across providers.

See the co ai guide, OIP WebSocket protocol, and Codex adapter reference.