[FEATURE] Desktop: a way to review a batch of suggested-task chips before accepting them

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Suggested-task chips stack vertically, and each one's accept button lands in the same screen position as the one above it. The prompt is not visible on the card; reading it means clicking into the chip first, then coming back out.

So the lowest-effort path through a stack of six is clicking the same pixel six times, and reading is uphill against the layout. That is fine when a chip is what the feature was designed for, a single opportunistic follow-up. It stops being fine when chips are used as a fan-out primitive.

I use them that way. A dispatcher session spawns one chip per backlog item, each carrying a task prompt, and each accepted chip starts a full Claude Code session that writes code, commits, and opens a pull request. Last batch was six chips. I accepted all six without reading any of them, not because I did not care but because the interface put six accept targets in one spot and the content behind a separate click.

That is a meaningful gap for an accept action whose payload is an autonomous coding session. The click reads as consent, and structurally it is closer to a batch acknowledgement.

Worth separating from two neighbours:

• #70388 is about chips behind the front one being unreachable. This is about chips you can reach fine being hard to review.
• #83791 asks for a persistent task inbox. That would incidentally create a review surface, and if it lands this may be subsumed. Filing separately because the review problem exists whether or not chips persist.

Proposed Solution

Some way to see what a batch of chips actually contains before accepting any of it. A few shapes, roughly cheapest first, and I do not have a strong preference between them:

• Show the first line or two of the prompt on the card, so the stack is skimmable without clicking in.
• A batch view: one scrollable list of pending chips with their full prompts, and accept controls there.
• Do not co-locate accept targets across stacked cards, so accepting several is a deliberate act each time rather than one repeated motion.
• An explicit "review all" affordance on a stack above some size.

The property that matters is that reading the batch costs less than accepting it, or at least not dramatically more.

Alternative Solutions

The workaround I landed on is to have the dispatcher write the whole wave to a file and read that instead of the chips. It works, but it duplicates content that is already in the chips, it is only as current as the moment it was written, and nothing connects the file to the accept action, so the two can drift.

I also shortened the chip prompts substantially, on the theory that length was what made them unreviewable. It did not help. Length was not the constraint; the affordance was.

Disabling the chips entirely (#72915) is not what I want. They are the right spawn mechanism, and they run under normal permission gates. The gap is only in reviewing a batch of them.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

Parallel dispatch across a backlog. A dispatcher session picks N independent items, verifies each defect still reproduces, works out which files collide, chooses a model per task, and spawns one chip per item. Each chip's prompt carries what the dispatcher measured, where the backlog row has gone stale, and the specific trap to avoid.

That prompt is the highest-leverage thing to review in the whole workflow. It is where the approach gets decided, and a reframe at that point costs nothing to act on, whereas the same reframe at pull-request time costs a rewrite.

It is also the moment the interface makes hardest to review.

Additional Context

Six chips in the batch that prompted this. Claude Code desktop app.

The prompts were short by then, deliberately, roughly two hundred words each rather than nine hundred, with a repo-local skill carrying the boilerplate instead of restating it per chip. Even so, none were read, because the shortening did nothing about where the content sits relative to the button.