[Bug]: Fall back to the integrated browser when pull requests cannot load

[ji233-Sun]

Before submitting

• I searched existing issues and did not find a duplicate. [Bug]: Pull Requests page fails with "GitHub CLI command failed" when gh uses a GitHub App installation token #11247 is a related example of a list-loading failure; this issue is about the UI fallback across such failures.
• I included enough detail to investigate the problem.

Area

apps/web

Steps to reproduce

1. Open a project whose repository's pull request page is accessible in the browser.
2. Cause the native pull request list request to fail (for example, the GitHub CLI authentication failure described in [Bug]: Pull Requests page fails with "GitHub CLI command failed" when gh uses a GitHub App installation token #11247).
3. Open Pull Requests with that repository selected.

Expected behavior

When the native PR list fails to load and T3 Code can resolve the selected repository's PR page URL, open that page in the integrated browser as a fallback. Keep a way to retry the native PR view and make the load failure visible without replacing the entire page with an error state. Use the repository's actual host URL, including for non-GitHub providers and self-hosted instances.

If the repository URL cannot be resolved or the integrated browser is unavailable, retain the current error and Retry behavior.

Actual behavior

The page displays Could not load pull requests with a Retry button and no in-app path to the repository's PR page. On current main (d15210c), the list error branch renders PullRequestsUnavailableState whenever the list query fails with no results. That state component only offers Retry unless a GitHub URL is explicitly supplied; this caller supplies none.

Impact

Major degradation or frequent failure: a PR-list error prevents browsing pull requests inside T3 Code even when the repository's web page remains accessible. The fallback would preserve access while the native integration is unavailable.

Version or commit

main at d15210c (code path verified; no local runtime reproduction).

Environment

Not tied to a particular OS or browser. The example in #11247 uses a GitHub App installation token for gh.

Workaround

Open the repository's PR page separately in a browser.

[juliusmarminge]

Triage

The empty-list failure screen is the current failure UI, and the code citations match main at d15210c. When the list query errors and no rows are on screen, _chat.pull-requests.tsx renders PullRequestsUnavailableState with the error text and Retry only. A later failure that still has rows does not replace the page: it keeps the last list and shows a warning with Retry.

PullRequestsUnavailableState can also render an external "Open on GitHub" link, but only when a caller passes gitHubUrl. The only caller that does is the pull request detail panel, and only through gitHubPullRequestBrowserUrl, which requires a GitHub repository and a specific pull request number. The list error has no number, and that helper returns null for GitLab, Forgejo, Bitbucket, and Azure DevOps. There is no helper that builds a repository's pull-request index URL (/pulls, /-/merge_requests, /pull-requests, and so on).

Opening that page in the integrated browser is a new capability, and the pull requests page cannot host one today:

• Preview tabs belong to a real thread, and only the desktop app has an integrated browser (window.desktopBridge.preview). On web, useOpenLink sends the URL to the system browser because there is no thread to open beside.
• This page's right panel is a synthetic workspace ref (pull-requests-panel), not a server environment a preview session can be opened on. The panel sets browserAvailable={false}, passes no preview sessions, and leaves onAddBrowser as a no-op. It only renders pull request detail.

The GitHub App installation-token failure in #11247 is a separate open bug. Listing still identifies the viewer with gh api user inside captureVerifiedCredential, which installation tokens cannot call. A browser fallback would not fix that.

Leaving this open as an enhancement. The existing workaround is the one that matches the current surfaces: open the repository's pull request page in a browser. A narrower follow-up, if we want one, is an external link on this error state when a single selected repository has a resolvable web URL — not an in-app browser on this page.