ConnectOnionAll Posts

Design Journal · August 16, 2026 · ConnectOnion 1.7.0a15

A Work Room Is a Summary, Not a Transcript

Why long native coding work needs a finite OIP summary, verified decisions, and honest evidence instead of a miniature terminal or a fabricated thumbnail.

Updated August 23, 2026: this article records the initial alpha simplification. The no-transcript decision was superseded after real client testing: current Work Room keeps attributed conversation and a provider-targeted composer visible. Read the current remote-client decision.

Long-running coding work made the old card look busy without making it useful. A person could see tool-shaped detail, a text snapshot, an approval button, and a history at once, yet still have to search for the answer that mattered: what is happening now, does it need me, and what can I safely do?

The decision

The parent conversation contains one compact semantic summary: the provider, a safe task category, the current state, and one entry action. This alpha initially made the Work Room a summary-only surface with no default transcript. Client testing later showed that removing attributed messages and input crossed the line from progressive disclosure into process deletion. The current contract keeps conversation and composer, while raw commands, nested scroll regions, and simulated terminal screenshots remain absent.

Truthful evidence has a narrow boundary

Codex and Claude Code each keep their private protocol. At the adapter edge, ConnectOnion translates only a finite OIP vocabulary: provider lifecycle, semantic activity, and a verified approval presentation. React accepts that vocabulary and rejects arbitrary provider text. O Chat renders the normalized state; it never parses provider JSON-RPC or treats a filename, command, or model message as browser authority.

A visual preview is intentionally absent until a provider supplies a real renderable artifact. Activity is labelled as activity. That is less flashy than a fake thumbnail, but it is the only honest representation of a coding run that has not produced an image.

Approval and Stop are different actions

When a native provider asks for permission, Core supplies the human-readable what, where, and why after checking the Work Room boundary. The visible choices are Allow once and Reject this request. Reject resolves that request; it does not pretend to kill the provider. Stop appears only while a provider is starting or running, carries the exact provider invocation ID, and closes only that invocation.

Evidence before the claim

The release acceptance used a disposable localhost Host with a real native Codex app-server. Codex created and tested a small C sorting exercise, paused for two one-time approvals, and left a strict C11 rebuild and test run that passed independently. A separate run targeted Stop at the live invocation and reached a cancelled terminal state while the outer Host turn completed. Browser regression then covered the compact desktop card, long activity history, approval placement, terminal failure, targeted Stop, and 375px and 320px layouts.

What remains deliberately separate

Model-reviewed Auto approval is still a later, fail-closed policy feature; it is not a disguise for approvalPolicy=never. Continuation chat and visual artifacts also wait for their own typed OIP contracts and real sources. None of this reintroduces ACP or a generic third coding adapter.

See An Approval Is Not Execution Time, the Codex adapter reference, and the co ai guide.

Star us on GitHub

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