Group plugin-rendered tool rows under Tool call display: Summary

[luoph]

What are you trying to do?

Fold a run of consecutive tool calls into one expandable row, so the assistant's next reply isn't pushed far down the chat. Our plugin, Better Paseo, renders every tool_call through a timeline transformer, and a contributor asked for exactly this: RoundRedDot/better-paseo#2.

How do you do it today?

Paseo already does it: Settings → Tool call display → Summary groups a run into one row ("Edited 2 files, ran 3 commands") that expands to the calls. With a plugin that transforms tool_call, Summary has no effect: every call stays its own row.

The contributor worked around it inside the plugin. Every call keeps its row; the first draws a header and the rest render empty. Source adjacency comes from reading the agent timeline (up to 10 pages on first mount, one tail read per new call). On web, injected CSS (div:has(> [data-…]), keyed to agent-chat-scroll and the display: contents wrapper) hides the empty rows' host wrappers. On iOS and Android there is nothing to hide, so on Paseo 0.12 each empty row keeps its 16 pt row margin (#6599): a folded run of 10 calls still leaves about 144 pt of blank space.

Where does Paseo get in the way?

createStreamPresentation (agent-stream/presentation.ts) runs projectPluginTimelineItems before prepareToolCallHistory, and isGroupableToolCall (tool-calls/detail-level/grouping.ts) accepts only kind === "tool_call". A projected row is kind: "plugin", so it never joins a run. Transforming first is right: since #4673 a plugin sees every call. But the plugin can't group on its own either: a transformer sees one item, its result is cached per item, and nothing lets it hide a host row or that row's margin.

What would a better workflow look like?

Under Summary, plugin rows projected from a groupable tool_call join the run like the native row they replace:

• A projected row keeps a reference to its source tool call (next to the sourceKind from fix(app): stack plugin-projected tool rows like native tool rows #6602), so buildOverviewGroup takes its counts and loading state from the source data. All rows projected from one call count as that one call.
• The group header stays native: the badge on wide layouts, the sheet on compact ones.
• Expanded, each member renders the way it renders in the stream: plugin rows through their plugin renderer, native rows as today.

Full detail, and plugins that don't transform tool_call, behave as before. Plugins need no new API, and since Summary is a per-client app setting, people choose it per device, which a plugin's host-scoped settings can't offer.

Happy to send a PR with tests and web/iOS QA if this direction works for you.

[joeshull]

Would love this. Tool rollups are one of my favorite parts of the Codex experience, and it’d be great to keep them when using plugins.

[glyphloom]

Another case for this, from Claude Look, a plugin that folds the steps between two replies into one row the same way. Besides the blank rows on phones, grouping in a plugin goes wrong a second way: it mixes sessions.

transform gets { item, phase } and no agent, so a plugin can only group by the order items are fed in, and that order interleaves sessions. Hidden tabs stay mounted but freeze (useRetainedValue in agent-stream/view.tsx), so a tab shown again transforms everything it missed in one batch, straight after the previous tab's items. Split panes and subagent panels transform side by side.

Reproduced on main (72e3316), production web build, with Claude Look 691de63 and two Claude agents in one workspace, running sleep 4 && echo alpha-N 25 times and sleep 4 && echo bravo-N 12 times:

1. Show bravo's tab, and leave it in the gap after one command finishes and before the next starts.
2. Show alpha's tab for 10 s, then bravo's for 6 s, then alpha's again.
3. Alpha's group now lists bravo-3 to bravo-5 among its own steps, and every later bravo step keeps joining it. Bravo's tab finishes showing 2 of its 12 commands. After a reload, neither tab shows the other's steps.

Alpha's group	Bravo after "done"

Grouping natively as proposed here avoids this too, since Paseo groups each view's own items.

Knowing the view is enough to fix it. To check, I made the plugin wrap useInstalledTimelineTransform at runtime and note the pane's tab while each transform runs, then group per tab. That relies on internal names and works only on web and desktop, but with it the same sequence keeps every step in its own tab:

Alpha's group	Bravo after "done"

If native grouping isn't the direction, passing the view's agentId into transform (renderers already get it) would let plugins group correctly on every platform. I have that change with a regression test, about 30 lines, and can open it if you want it.