A sidebar layout setting and fixes for when an agent is waiting: one PR, or a split?

[quanticstudios]

What I am proposing

#32071 is one PR of 36 commits and a merge of main: a sidebar layout setting, a set of defect fixes at the points where an agent stops and waits, and five changes of taste behind settings that default to what users have today.

I opened it without the approval CONTRIBUTING.md asks for, and it solves more than one problem, which the same file does not allow. I would rather you see the working thing than a description of it, and I know that is not how your process runs. So it needs your decision, and closing it is a fair answer. If you want pieces of it, tell me which and I will open focused PRs.

Why I built it as one

• The changes share one subject. An agent stops, and the app goes quiet at that moment. The sidebar, the approval row, the status label, the failure banner and the window title are each part of that.
• They were measured together, on one seed, against main.
• Each commit can be read and taken on its own. The split in the PR has not been tested.

The argument against is real. It is a lot to review from an outside contributor, your review capacity is limited, and some of these reverse recent choices (#26255 made the approval actions inline).

What is in it

For everyone, because they are defects: Allow and Deny as real buttons, "Waiting for you" in place of "Working for" while blocked, a thread on approval no longer receding, dim text raised, 24px hit areas, number keys on questions that work without stealing typed text, no floating copy of a failure that has its own row, and correct wording on read-only settings pages.

Behind a setting, off by default, because they are taste or change what someone relies on: a neutral stop button while a thread waits, a shimmer on the chat's Working row, hiding the provider logo when only one exists, a waiting count in the window title, and terminal actions off the first line, which costs about two terminal rows.

A sidebar layout setting, default unchanged: Default, Detailed and Slim. Detailed and Slim keep threads in place when their state changes. Their rows copy pitwall's, which is my own project. That is a bias, so weigh it.

What I measured

All from a real web app on seeded, made-up data, with a harness that is not on the branch.

• The active list, measured on the earlier base 337c5858: on 15 seeded rows, four state changes moved 8 rows to a different slot, some by up to 886px. Neither new layout moved a row on those state changes. A request arriving moves rows below it in Detailed only.
• Default against main: on 30 screens, every differing pixel falls in a region an always-on commit names, except 34 pixels on one screen. They come from commit 6, and I can't say which line. With every new setting off, each setting's commit changes 0 pixels on those thread screens.
• Allow and Deny: 29×16 and 28×16px, now 45×24 and 44×24.
• A question with focus outside the answer box: pressing 2 picks the option and moves the counter from 1/3 to 2/3. Typing "Use 2 fields" lands intact in the box, including right after picking the thread in the sidebar. 29 live checks pass.
• Contrast is only partly solved. Detailed and Slim pill text reaches 4.5:1 on all 12 themes, and so do the palette and the settings pages. Working rows stay under 4.5:1 on Grove, Ocean, Ember and Iris, with the theme's own tokens at full strength. The provider mark stays under 3:1 on light themes and Grove dark, because I did not recolour Claude's orange. The tables are in the PR.
• GPT-6.1 Sol in Codex read the later commits from the code, without running them, and found three real defects, which are fixed.

Not checked: Mac text widths (my captures use a Linux fallback font), desktop shell, mobile, screen readers, a real provider, or anyone using this day to day. The scores in the studies are one reviewer's judgment.

Two unofficial studies, neither made by nor endorsed by T3, explain this in detail. Both measured commit 337c5858, an earlier base: https://8d0d5a98.qstech.pages.dev/sidebar-study and https://8d0d5a98.qstech.pages.dev/full-sweep.

Related: #31157 asks to nest child threads, #30980 asks to keep the Working section in the Boring sidebar and Detailed and Slim go the other way, #17319 asks for compact rows, #29556 keeps working threads in place on refocus, #28113 is about shimmer's battery cost on mobile.

What I would like you to decide

1. One PR, or a split? If a split, which pieces do you want?
2. Is a layout setting something you want, or would you rather change Default, or leave this alone? If yes, both layouts or one? My pick is Slim, whose row hook is the smaller, though only Detailed shows workers in the list.
3. Are the five settings acceptable, or would you rather decide each one and not add a setting?
4. Are answers on a row acceptable? An approve button that appears without opening the thread carries some risk.

Written with Claude Opus 5.5 in Claude Code. I checked the numbers against the runs.