Feature: Add an Issues panel alongside Pull Requests

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

T3 Code now has a Pull Requests panel, which makes it easy to see review work without leaving the app. It would be useful to have a companion Issues panel so developers can browse and open the issues that drive their work from the same workspace.

Today, users need to context-switch to their forge to find an issue, read its details, then copy the relevant context into T3 Code.

Proposed solution

Add an Issues navigation item alongside Pull Requests. It should use the same project/repository and source-control-provider context as the Pull Requests surface.

The panel should let users:

• list open issues for the selected repository, with search and basic filters;
• open an issue to view its title, description, labels, assignees, status, and comments;
• open the issue in its provider as an escape hatch;
• create a new T3 Code thread from an issue, pre-populated with its context.

Why this matters

Issues and pull requests are complementary parts of the development workflow. Keeping both visible in T3 Code would reduce tab switching and make it easier to go from planned work to an agent task and then to review.

Smallest useful scope

For the first iteration, show open issues for the active GitHub repository and provide issue details plus an Open in GitHub action. Creating a thread from an issue can follow in the same feature or as a subsequent iteration.

The design should remain provider-aware, so other supported source-control providers can add issue/work-item support later.

Alternatives considered

• Keep using the browser or a separate issue tracker: works today, but requires repeated context switching and copying.
• Add issue links only in chat: useful for a single known issue, but does not provide discovery or browsing.

Risks or tradeoffs

• Providers expose different issue/work-item concepts and filter capabilities. A GitHub-first implementation with a clear provider interface would keep the first version focused.
• Listing issue metadata should be paginated/cached to avoid slowing the main thread UI.

Examples or references

The existing Pull Requests navigation is the intended UX reference.

Contribution

• I would be open to helping implement this.

Start in apps/web by tracing the existing Pull Requests navigation and its project, repository, and source-control-provider context. Define the smallest GitHub-first scope: browse open issues, show issue details, and provide an Open in GitHub action. Done means the Issues panel works alongside Pull Requests without blocking later provider support.