Proposal: make an agent turn readable at a glance on a phone

[jankarres]

This is an opinionated proposal for the chat view, and a proposal is really all it is: I have not thought every element through to the end, and some of it will touch parts of the app I have not looked at closely. I am mostly putting it up to ask whether there is any interest in this direction at all. A no is a perfectly good answer, and I would rather hear it now than keep polishing something nobody wants.

It comes out of how Claude Code presents itself in Visual Studio Code. I live in that view all day, and following the same turn on my phone is much harder, which is where this started.

Interactive before and after mockup: mockup.html

Why

The row is the thing a chat produces most: one per tool call, and dozens of them in a single conversation. It is the element I spend the most time looking at, and it is the one that tells me least.

Two shell calls, as the app renders them today and as this proposes:

Today	Proposed

On the left, both rows say Ran command and then the start of the shell command, which on a phone is the part every call has in common: the cd into the project. The two rows are identical up to the point where they are cut, so nothing on screen tells them apart, and nothing says what either call was for or what came back. Both rows are only visible at all because I expanded them; by default the second one sits behind +1 previous tool call.

On the right the same two calls say what they were for and what they produced, without expanding anything. The command is still there, one tap away.

The change that does most of that work is one lookup. Every shell call already arrives with a short description of what it is for, "Check branch state", and the row renders the raw command instead. It was set on all 147 shell calls in the transcripts I went through, so it is a field that is there and unused rather than one that is occasionally available.

It gets worse when an agent works through several files in one directory, which it does constantly. A row is cut at its end, and for a path the end is the filename, so the one part that tells the rows apart is the part that goes:

Today	Proposed

Four reads, four rows, one string repeated. This is where I started: not with a feature, but with the feeling of scrolling past a wall of rows that all look the same and tell me nothing. Where rows really are interchangeable they now become one, with the filenames kept as chips, which also gives back three rows of height.

At the scale of a whole turn it compounds, because the rows that look alike are also the rows that get folded away:

Today	Proposed

Same turn, same data, both at phone width. On the left, four file reads and five shell calls collapse into two rows plus +5 previous tool calls and +2 previous tool calls; the paths are cut at the end, so the filenames are gone; and a step that failed is hidden inside a fold. On the right the same turn reads as a list of sentences, each with its outcome, and the failure is visible without opening anything.

What changes

A finished turn says what it did. Counts by kind next to the duration, and the files it touched underneath the answer, both built from things the transcript already carried.

Today	Proposed

A permission shows the command once, in full. Today it appears twice, as the heading and again below it, in a block that caps its own height, so half the card is a duplicate and the reply buttons get pushed down.

Today	Proposed

Coming back to a turn that ran without you. Much like the unread line in a Slack channel, a rule marks where you stopped reading. On a phone that earns its place more than on a desktop, because you put the phone down mid-turn and come back to twenty new steps. Here the rule is also the control that takes you to the newest work, and it is anchored to what was on screen when you left rather than to how far you scrolled.

The composer. The three session settings share one row and are told apart only by their colour, and when the values run long they collapse to single letters. Each now carries a small glyph for its category, so the mode and the model are distinguishable without decoding a colour, and the context meter becomes a ring you can tap for the figure.

Today	Proposed

Long values still get cut, though: three settings and three buttons do not fit one line at this width. Fitting all of them needs a second line, which would be a proposal of its own.

What it touches

src/pages/chat/ only. No protocol change, no host version, no new theme token, no new dependency, no new copy to translate. It reads fields the host already sends, so it works against every CLI in the field.

It comes with 103 new tests. The decisions about what a row should say now sit in small pure functions with tests beside them rather than inside the components, which is the split this repository already uses elsewhere. That refactor also turned up dead code: the line meant to say what the agent is doing could never render, so a running turn only ever said Working for 34s.

Decisions you may want to overrule

Four places where I picked one option. The alternative is named in each.

• How much of a turn is on screen. Today a turn shows only its most recent action, with the earlier ones behind a counter. This shows all of them, oldest behind a single control, because not being able to see what the agent just did is the complaint this started from. Latest-only stays available as a setting rather than being removed.
• Which repeated rows collapse. A run of file reads differs only in a filename, so it becomes one row with the names as chips. A run of shell calls does not collapse, because each carries its own description and folding a dozen would replace a dozen sentences with a number. The alternative is one rule for both, which either throws away the descriptions or leaves a wall of near-identical file rows.
• Whether the transcript is read aloud as it grows. It is marked up as a log but announces nothing, because a turn can append twenty-five rows and hearing each one is unusable; the turn header speaks once, when the state changes. The alternative is the automatic announcement a log role normally brings.
• Where the rule for missed steps sits. It goes above the whole turn rather than between the exact two steps, because the new steps arrive inside a single message and placing it precisely would mean rendering that message's work log in two halves. The alternative is exact placement at the cost of that split.

Feedback

I would be glad of any. If the direction appeals, I am happy to keep working on it inside this pull request, particularly the last details and the places where these elements meet other parts of the app, which is where my thinking is thinnest. And if you would rather take the idea and shape it yourself, please do!