One Browser Protocol, Native Coding Adapters

ConnectOnion 1.7.0a5 makes OIP 0.1 the only first-party browser protocol. 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.

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.

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.

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; OIP Host contracts; session resume; and a real published-package browser run.

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.