ConnectOnionAll Posts

Design Decision · August 17, 2026

The Work Room Is a Client, Not a Status Panel

Remote control needs a real conversation surface without making the browser a second runtime.

A one-message demo can make a coding agent look finished long before it has done anything useful. A proper acceptance run needs to inspect a workspace, write a small program, compile it, run tests, pause for a decision, and continue. That is when a product learns whether its interface is reporting work or merely accumulating boxes.

The decision

ConnectOnion Core is the one writer of native coding-provider state. The React package validates and normalizes that bounded OIP state. O Chat renders one compact parent card and one continuous remote client with attributed conversation, live work, provider controls, and a fixed composer.

One writer, defensive readers

Codex and Claude Code are native providers. Their adapters translate provider lifecycle into typed OIP events with a provider, invocation identity, revision, semantic activity, bounded message, approval and optional real image evidence. Core decides what is safe to expose. It does not send raw commands, paths, hidden prompts or terminal output to the browser.

@connectonion/react does not reconstruct that state from a chat transcript. It validates the envelope, rejects stale authority, and keeps the correlation needed for reconnect and direct input. O Chat does not implement a second provider adapter. It reads the normalized state and renders it.

Why the first simplification went too far

The first design put a conversation panel, a status card, a preview panel, an activity list and a composer next to one another. Each element was reasonable in isolation, but together they made the reader decide where to look before they could understand what Codex was doing.

The answer was hierarchy, not deletion. A Work Room is the remote client for a Codex or Claude Code session, so attributed user and provider messages, current lifecycle, meaningful work, and the provider-targeted input must remain recognizable. Earlier technical activity can fold away; the conversation cannot.

The current hierarchy asks what is happening now? at the top, then keeps the native conversation in one reading flow and the composer fixed at the bottom. Approval becomes the primary action, but it does not erase the conversation or input. If approval, Stop, reconnect, provider-busy, or an older Host prevents sending, the input remains visible and explains why it is disabled.

Evidence is not decoration

A Codex thumbnail is useful only when it is actual provider evidence for the current invocation revision. Text and terminal output must not be dressed up as a screenshot. If the provider has no verified raster, the card remains text-first. That is a truthful absence, not an incomplete simulation.

The same rule applies to direct messages. A Work Room message is not called sent because a host queued it. The browser retains its draft until live Codex accepts turn/steer, or a resumed native thread accepts a new turn/start. The acknowledgement therefore describes an event that happened, rather than a request that might happen later.

What this alpha proves

  • One compact parent-card action opens the Work Room.
  • A long native run stays readable on desktop and a 375px phone width.
  • User and provider messages remain attributed while earlier technical activity stays folded.
  • Codex and Claude Code keep a provider-targeted input in every lifecycle state.
  • Approval, Stop and native direct input retain their own honest lifecycle boundaries.
  • Initial semantic focus announces the task heading without styling that non-interactive text as a control; buttons and the composer keep visible keyboard focus.
  • Only native Codex and Claude Code adapters participate in this release path.

This is intentionally a preview boundary, not a promise that every future coding feature belongs in the Work Room. Automatic approval and deeper autonomy need their own policy and review design. For now, the product proves that a real native run can remain calm, inspectable and truthful.

Star us on GitHub

If ConnectOnion saves you time, a ⭐ goes a long way — and earns you a coffee chat with our founder.