A Tool Transaction Is Not a Work Room

A native coding provider can run for minutes, call several tools, pause for a command approval, and then continue in the same provider session. Treating all of that as one generic tool row makes the running work look silent until it is over. Treating it as a raw transcript makes chat unreadable.

The product question

A Work Room must answer four questions at a glance: what is the provider doing now, how much has happened, whether a person needs to decide something, and where to find the detail if it matters. It must still work after eight or more native steps, on a phone, and after a provider session resumes.

Alternatives considered

• Show only the parent tool transaction after it finishes.
• Put every provider event, command, and output straight into the chat transcript.
• Render a fabricated terminal or browser thumbnail from text.
• Stream correlated semantic activity into one provider Work Room and disclose raw detail only on demand.

Decision

OIP keeps the ordinary message and cancellation lifecycle, while the Codex and Claude Code adapters emit a small live provider lane. Each activity carries the provider invocation identity; an approval carries that same invocation and its parent tool call. O Chat can therefore put the approval inside the card that caused it instead of creating a second, unrelated approval row.

The card and full Work Room show a truthful live activity snapshot: the newest semantic step, status, duration, and a bounded newest-first activity list. Commands and outputs live behind an explicit disclosure. This keeps the conversation useful even when the provider has produced many steps.

Why there is no pretend screenshot

Codex's native adapter does not currently emit a screenshot or other visual artifact. A generated terminal image would look like evidence but would not be evidence. The UI therefore labels the compact preview as an activity snapshot. If an adapter later emits a real, safely scoped image artifact, the Work Room may render that actual artifact as a thumbnail; it must never invent one.

Tradeoffs and acceptance

Streaming adds a provider-specific translation path, but it makes cancellation and approval state visible while work is actually running. The acceptance path uses a real multi-step coding task: create and run a small Python algorithm, verify at least eight steps, pause for a harmless command approval, inspect desktop and phone layouts, then confirm that cancellation reaches a terminal state without leaving a stale approval.

This is deliberately not an ACP feature. OIP remains the browser boundary, and Codex and Claude Code remain native backend adapters. A future Auto mode is a separate, model-reviewed and fail-closed approval policy; it does not weaken the default manual approval boundary.

See the OIP/native-adapter decision, the co ai guide, and the Codex adapter reference.