The workflow
I keep several projects in the sidebar and work across them through the day. One of them accumulates a long thread list. To reach a project below it I have to scroll past every thread in the noisy project first, and the projects underneath spend most of their time off screen.
What happens today
The sidebar is one flat scroll. A project's thread list is unbounded, so a project with many threads pushes every project below it down by its full height. The two available responses both cost something:
- Collapse the project. Its threads become unreachable without expanding it again, which puts me back where I started.
- Scroll. Reaching a project low in the list means traversing the whole thread list above it every time.
There is no way to cap how much vertical space one project spends while keeping its threads reachable.
What you would expect
An optional per-project maximum number of visible thread rows, defaulting to off so nothing changes for anyone who does not set it. A project with a limit shows that many rows and scrolls natively inside its own bounded viewport; the full ordered thread set stays present, and selecting a thread outside the current window scrolls it into view. Projects below it stay where they are.
Concrete shape, as a prototype on my fork: https://github.com/MPIsaac-Per/bb/tree/feat/project-thread-row-limits
projects.sidebar_thread_row_limit, null meaning unlimited, values 5, 10, 20, 50.- The control in Project settings, plus
bb project update <id> --thread-row-limit <5|10|20|50|unlimited> and the same field through the SDK.
ProjectRow wraps its existing ProjectThreadTree in the bounded viewport, so thread order, collapse state, drag behavior, and keyboard navigation keep their current data and DOM order. Native scrolling only, no modal primitive, no app-root inerting.
Context and alternatives
Workaround today is collapsing the noisy project and expanding it whenever I need it, which trades one problem for the other.
#2525 proposes browser-style tabs above the chat for open threads. That addresses the same crowding from a different direction and the two are compatible; this one is about the sidebar staying navigable rather than about reaching recently open threads.
I have a branch ready, but per CONTRIBUTING.md I am filing this first rather than opening a PR. Happy to adjust the shape, drop the CLI surface, or take a different approach entirely if this is not the direction you want.
Checks
AGENT GENERATED
The workflow
I keep several projects in the sidebar and work across them through the day. One of them accumulates a long thread list. To reach a project below it I have to scroll past every thread in the noisy project first, and the projects underneath spend most of their time off screen.
What happens today
The sidebar is one flat scroll. A project's thread list is unbounded, so a project with many threads pushes every project below it down by its full height. The two available responses both cost something:
There is no way to cap how much vertical space one project spends while keeping its threads reachable.
What you would expect
An optional per-project maximum number of visible thread rows, defaulting to off so nothing changes for anyone who does not set it. A project with a limit shows that many rows and scrolls natively inside its own bounded viewport; the full ordered thread set stays present, and selecting a thread outside the current window scrolls it into view. Projects below it stay where they are.
Concrete shape, as a prototype on my fork: https://github.com/MPIsaac-Per/bb/tree/feat/project-thread-row-limits
projects.sidebar_thread_row_limit, null meaning unlimited, values 5, 10, 20, 50.bb project update <id> --thread-row-limit <5|10|20|50|unlimited>and the same field through the SDK.ProjectRowwraps its existingProjectThreadTreein the bounded viewport, so thread order, collapse state, drag behavior, and keyboard navigation keep their current data and DOM order. Native scrolling only, no modal primitive, no app-root inerting.Context and alternatives
Workaround today is collapsing the noisy project and expanding it whenever I need it, which trades one problem for the other.
#2525 proposes browser-style tabs above the chat for open threads. That addresses the same crowding from a different direction and the two are compatible; this one is about the sidebar staying navigable rather than about reaching recently open threads.
I have a branch ready, but per CONTRIBUTING.md I am filing this first rather than opening a PR. Happy to adjust the shape, drop the CLI surface, or take a different approach entirely if this is not the direction you want.
Checks
> AGENT GENERATED.