GitHub Issues Sidebar Gets Pinned Views, Density Controls, and API Scoping

GitHub has shipped four quality-of-life improvements to its Issues product. The headline change: saved views from GitHub Projects can now be pinned to the repository issues sidebar, staying accessible in a single click even when the sidebar is collapsed. Alongside that, the Issues Dashboard has a new density control, reactions now show profile avatars, and the issue dependency REST API tightens results to match each token's permission scope.

What happened

Feature	Detail
Pinned sidebar views	Saved views can be pinned to the repository issues sidebar; accessible even when sidebar is collapsed
Issues Dashboard density	New density setting lets users see more issues at once
Reaction avatars	Profile avatars now visible on issue reactions
API scope filtering	blocked_by, blocking, and relates_to endpoints now filter by token’s granted scope

All four changes are now generally available on GitHub. The pinned views feature is the most structural: previously, finding a specific saved view required navigating into GitHub Projects. Now it sits directly in the repository issues sidebar, reducing clicks for teams that live inside their issue tracker.

Why it matters

For engineering teams managing large backlogs, small navigation improvements compound quickly. Pinning a “My open bugs” or “Sprint 14” view to the sidebar means less context-switching between Projects and the repository itself. The sidebar stays usable even when collapsed, so teams on smaller screens do not lose the shortcut.

The density control is practical for anyone doing triage. Fitting more rows on screen without scrolling is a small change that saves real time during sprint planning or bug reviews.

The API scoping fix matters most to teams using fine-grained personal access tokens or GitHub Apps with limited permissions. Before this change, the dependency endpoints could return issue relationships that the token had no business seeing. Filtering by granted scope closes that gap and makes the API behave consistently with how the rest of GitHub handles token-based access.

Our take

None of these are flashy, but they are the kind of changes that signal a team actually uses its own product. Pinned sidebar views in particular addresses a real friction point: GitHub Projects is powerful but sits at arm’s length from the repository issues view. Bridging that gap without forcing users to rebuild their workflow elsewhere is the right call.

The API scope filtering is worth calling out separately. It should have been the default from day one. If you build internal tools or workflow automations on top of the GitHub Issues API, audit your tokens now and confirm you are not relying on over-broad results from those three endpoints. Tighter scoping is correct behavior, but it could quietly break an automation that assumed full visibility.

If your team tracks project delivery through GitHub Issues, these updates are worth a quick test this week. For a broader look at how we think about developer tooling and web development workflows, our services page has more context on what we actually ship for clients.

What to do about it

1. Open your repository, go to the Issues sidebar, and pin the saved views your team uses most often.
2. Adjust the Issues Dashboard density setting to match your screen size and triage style.
3. Review any GitHub Apps or personal access tokens that call the blocked_by, blocking, or relates_to REST endpoints, and verify the scope is set to what you actually intend.
4. Test automations that depend on those dependency endpoints in a staging environment before relying on them in production.

Source: GitHub Changelog