Feature: Add an Issues panel alongside Pull Requests

[Bombatomica64]

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.

[juliusmarminge]

Thanks for the clear write-up. This is a valid enhancement, not a bug.

Current state: main has no Issues surface. The sidebar only shows Settings, Pull Requests (gated on capabilities.pullRequests), and Usage. Users still leave the app to find the issue that should seed a thread.

Implementation home: the Pull Requests stack is the intended template:

• Nav/route: apps/web/src/components/sidebar/SidebarChrome.tsx, apps/web/src/routes/_chat.pull-requests.tsx
• UI: apps/web/src/components/pullRequest/*
• Client: apps/web/src/state/pullRequests.ts, packages/client-runtime/src/state/pullRequests.ts
• Contracts: packages/contracts/src/pullRequest.ts, packages/contracts/src/rpc.ts (pullRequests.*), packages/contracts/src/environment.ts
• Server: apps/server/src/pullRequest/PullRequestProvider.ts + PullRequestService.ts + PullRequestReadCache.ts + per-host adapters

A first iteration should add a parallel issues capability and list/detail RPCs, a /issues route, and a sidebar item. Keep it GitHub-first, paginated/cached, and provider-aware so other hosts can plug in later. Creating a thread from an issue can follow.

Related work (not duplicates):

• feat(issues): add multi-provider issue tracking #6315 (open, XXL) already implements a full Issues workspace across GitHub/GitLab/Bitbucket/Azure DevOps/Linear. Maintainers previously said that ~40k-line patch is too large and needs a smaller product/implementation path. Do not treat it as the merge vehicle for this request.
• feat(clients): add GitHub issue browsing #8046 (closed, not merged) was a closer GitHub-only browse + “Fix in a thread” slice.
• feat(linear): import Linear issues into new thread drafts #7065 (closed) and discussion [Feature]: Import Linear Issues to Create Threads (with Multi-Issue Support) #6752 cover Linear → thread import.
• Discussion [Feature] Faster way to start new workspace + worktree from GitHub issue or PR #10938 is adjacent: faster new workspace/worktree from an issue/PR, not a browse panel.

Suggested first slice (agrees with the report): open issues for the active GitHub repo, detail view (title, body, labels, assignees, status, comments), and Open in GitHub. Search/basic filters if they stay cheap. Other providers and thread prefill as follow-ups.

Keeping this open as the product request. enhancement.